pbrobinson authored Jul 10, 2020 and Justin M. Forbes committed Aug 12, 2020

The ACPI prefernce is RHEL specific, in Fedora we use upstream defaults so
it doesn't randomly change the expectations as to how certain hardware works
that generally isn't classed as "enterprise". So wrap it in the special RHEL
check as it should be for the ARK kernels.

Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
CC: Mark Salter <msalter@redhat.com>

Prarit Bhargava authored Jun 11, 2020 and Justin M. Forbes committed Aug 12, 2020

Upstream Status: RHEL only

After discussions with Devel, QE, Support, and Certification we have
decided to drop the CPU specific checks in rh_check_supported().
Certification is adopting a new process in which CPU certifications will
be tracked on https://catalog.redhat.com

.

Remove the vendor specific CPU ID checks from rh_check_supported().

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: David Arcari <darcari@redhat.com>

Prarit Bhargava authored Apr 13, 2020 and Justin M. Forbes committed Aug 12, 2020

Resending ... did not get any reviews.

P.

---8<---

Bugzilla: http://bugzilla.redhat.com/1810301
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=27902812
Local Tree: git://git.engineering.redhat.com/users/prarit/rhel8 1810301

Upstream Status: RHEL only

For almost a decade, RHEL kernels have output the message

"this hardware has not undergone testing by Red Hat and might not be
certified. Please consult https://hardware.redhat.com

 for certified
hardware."

for unsupported hardware.  This link should be now be updated to the
new catalog.redhat.com location.  The old hardware.redhat.com is now
redirecting to catalog.redhat.com for older releases.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: David Arcari <darcari@redhat.com>

Don Zickus authored May 14, 2020 and Justin M. Forbes committed Aug 12, 2020

Upstream status: RHEL only

The function rh_check_supported is a RHEL function to limit the
platforms RHEL does not want to support.

To avoid imposing this requirement on Fedora, the function was
wrapped with CONFIG_RHEL_DIFFERENCES so Fedora can disable this.

However, this has a few compile warnings that need to be cleaned up
when disabled.

Move CONFIG_RHEL_DIFFERENCES to include the functions themselves
instead of the call.  As the unused functions created warnings.

V2: modified stub definition

Signed-off-by: Don Zickus <dzickus@redhat.com>

Aaron Ma authored Mar 24, 2020 and Justin M. Forbes committed Aug 12, 2020

ME takes 2+ seconds to un-configure ULP mode done after resume
from s2idle on some ThinkPad laptops.
Without enough wait, reset and re-init will fail with error.

Fixes: f15bb6dd ("e1000e: Add support for S0ix")
BugLink: https://bugs.launchpad.net/bugs/1865570


Signed-off-by: Aaron Ma <aaron.ma@canonical.com>

Icenowy Zheng authored Mar 16, 2020 and Justin M. Forbes committed Aug 12, 2020

The max() function call in horizontal timing calculation shouldn't pad a
length already subtracted with overhead to overhead, instead it should
only prevent the set timing to underflow.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Icenowy Zheng authored Mar 16, 2020 and Justin M. Forbes committed Aug 12, 2020

Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
Xingbangda, which is used on PinePhone final assembled phones.

Add support for it.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Icenowy Zheng authored Mar 16, 2020 and Justin M. Forbes committed Aug 12, 2020

Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI LCD panel.

Add its device tree binding.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>

Masahiro Yamada authored Sep 30, 2019 and Justin M. Forbes committed Aug 12, 2020

KernelCI reports that bcm2835_defconfig is no longer booting since
commit ac7c3e4f ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly"):

  https://lkml.org/lkml/2019/9/26/825

I also received a regression report from Nicolas Saenz Julienne:

  https://lkml.org/lkml/2019/9/27/263

This problem has cropped up on arch/arm/config/bcm2835_defconfig
because it enables CONFIG_CC_OPTIMIZE_FOR_SIZE. The compiler tends
to prefer not inlining functions with -Os. I was able to reproduce
it with other boards and defconfig files by manually enabling
CONFIG_CC_OPTIMIZE_FOR_SIZE.

The __get_user_check() specifically uses r0, r1, r2 registers.
So, uaccess_save_and_enable() and uaccess_restore() must be inlined
in order to avoid those registers being overwritten in the callees.

Prior to commit 9012d011 ("compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING"), the 'inline' marker was always enough for
inlining functions, except on x86.

Since that commit, all architectures can enable CONFIG_OPTIMIZE_INLINING.
So, __always_inline is now the only guaranteed way of forcible inlining.

I want to keep as much compiler's freedom as possible about the inlining
decision. So, I changed the function call order instead of adding
__always_inline around.

Call uaccess_save_and_enable() before assigning the __p ("r0"), and
uaccess_restore() after evacuating the __e ("r0").

Fixes: 9012d011

 ("compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING")
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Reported-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Tested-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>

Murphy Zhou authored Sep 29, 2019 and Justin M. Forbes committed Aug 12, 2020

Now if DEFAULT_OFF set to y, kmemleak_init will start the cleanup_work
workqueue. Then late_init call will set kmemleak_initialized to 1, the
cleaup workqueue will try to do cleanup, triggering:

[24.738773] ==================================================================
[24.742784] BUG: KASAN: global-out-of-bounds in __kmemleak_do_cleanup+0x166/0x180
[24.744144] Key type ._fscrypt registered
[24.745680] Read of size 8 at addr ffffffff88746c90 by task kworker/3:1/171
[24.745687]
[24.745697] CPU: 3 PID: 171 Comm: kworker/3:1 Not tainted 5.3.0-v5.3-12475-gcbafe18c #1
[24.745701] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[24.745710] Workqueue: events kmemleak_do_cleanup
[24.745717] Call Trace:
[24.745736]  dump_stack+0x7c/0xc0
[24.745755]  print_address_description.constprop.4+0x1f/0x300
[24.751562] Key type .fscrypt registered
[24.754370]  __kasan_report.cold.8+0x76/0xb2
[24.754388]  ? __kmemleak_do_cleanup+0x166/0x180
[24.754407]  kasan_report+0xe/0x20
[24.778543]  __kmemleak_do_cleanup+0x166/0x180
[24.780795]  process_one_work+0x919/0x17d0
[24.782929]  ? pwq_dec_nr_in_flight+0x320/0x320
[24.785092]  worker_thread+0x87/0xb40
[24.786948]  ? __kthread_parkme+0xc3/0x190
[24.789217]  ? process_one_work+0x17d0/0x17d0
[24.791414]  kthread+0x333/0x3f0
[24.793031]  ? kthread_create_worker_on_cpu+0xc0/0xc0
[24.795473]  ret_from_fork+0x3a/0x50
[24.797303]
[24.798091] The buggy address belongs to the variable:
[24.800634]  mem_pool_free_count+0x10/0x40
[24.802656]
[24.803434] Memory state around the buggy address:
[24.805793]  ffffffff88746b80: 04 fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[24.809177]  ffffffff88746c00: 00 fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[24.812407] >ffffffff88746c80: 04 fa fa fa fa fa fa fa 00 00 fa fa fa fa fa fa
[24.815638]                          ^
[24.817372]  ffffffff88746d00: 00 00 fa fa fa fa fa fa 00 00 00 00 00 00 00 00
[24.820740]  ffffffff88746d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[24.824021] ==================================================================

Fixes: c5665868

 ("mm: kmemleak: use the memory pool for early allocations")
Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>

Robert Holmes authored Apr 23, 2019 and Justin M. Forbes committed Aug 12, 2020

This patch completes commit 278311e4

 ("kexec, KEYS: Make use of
platform keyring for signature verify") which, while adding the
platform keyring for bzImage verification, neglected to also add
this keyring for module verification.

As such, kernel modules signed with keys from the MokList variable
were not successfully verified.

Signed-off-by: Robert Holmes <robeholmes@gmail.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>

Benjamin Tissoires authored Apr 03, 2017 and Justin M. Forbes committed Aug 12, 2020

The IRQ from rmi4 may interfere with the one we currently use on i2c-hid.
Given that there is already a need for an external API from rmi4 to
forward the attention data, we can, in this particular case rely on a
separate workqueue to prevent cursor jumps.

Reported-by: Cameron Gutman <aicommander@gmail.com>
Reported-by: Thorsten Leemhuis <linux@leemhuis.info>
Reported-by: Jason Ekstrand <jason@jlekstrand.net>
Tested-by: Andrew Duggan <aduggan@synaptics.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Lyude <lyude@redhat.com>

pbrobinson authored May 03, 2012 and Justin M. Forbes committed Aug 12, 2020

Patch for disconnect issues with storage attached to a
 tegra-ehci controller

Jon Masters authored Jul 18, 2019 and Justin M. Forbes committed Aug 12, 2020

We will use this to force CONFIG_HIGHPTE off on LPAE for now

Signed-off-by: Jon Masters <jcm@redhat.com>

Jiri Benc authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Bruno Meneguele <bmeneg@redhat.com>
RH-Acked-by: Jesper Brouer <brouer@redhat.com>
RH-Acked-by: Prarit Bhargava <prarit@redhat.com>
RH-Acked-by: Jiri Olsa <jolsa@redhat.com>
RH-Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>

Upstream status: RHEL only

We don't really need the field names to be globally unique, it is enough
when they are unique in the given struct. Since structs do not generally
span mutliple files, using the line number is enough to ensure an unique
identifier. It means that we can't use two RH_KABI_RENAME macros on the same
line but that's not happening anyway.

This allows pahole to deduplicate the type info of structs using kABI
macros, lowering the size of vmlinuz from 26M to 8.5M.

Upstream Status: RHEL only
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Jiri Benc authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Prarit Bhargava <prarit@redhat.com>
RH-Acked-by: Don Zickus <dzickus@redhat.com>

Upstream status: RHEL only

We've seen attempts of incorrect RH_KABI_EXCLUDE usage. The macro is
dangerous and any structure marked by it becomes fragile. It completely
mutes the kABI checker and a future attempt to whitelist anything using
a structure annotated by RH_KABI_EXCLUDE will generate easily broken, error
prone code. Also, it bypasses module loading checks for the structure and
can lead to kernel crashes triggered by 3rd party modules unless carefully
prevented by RH_KABI_FORCE_CHANGE.

As such, it should not be used routinely. The only valid usage is a code
heavily in flux upstream that is going to be refactored and turned upside
down, which is indirectly whitelisted and which we expect to need
backported.

Any usage of this macro requires deep understanding of how kABI works.

Add a big fat warning to stop the misuse.

Upstream Status: RHEL only
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Jiri Benc authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
RH-Acked-by: Hangbin Liu <haliu@redhat.com>

Upstream status: RHEL only

This allows addition of a struct into struct while reserving extra space.
See the documentation in rh_kabi.h for details.

The check for size is automatically disabled in -debug kernels that have
many fields larger than the production kernels (mutexes etc.) and that are
not under kABI guarantee.

I'm also moving a misplaced comment for RH_KABI_FILL_HOLE.

(Pointed out by Sabrina:) We need to force align the added field to 8 byte
offset. Otherwise, if the required alignment of the added field changed
later (e.g. it was a structure with only a single field that was changed
from int to char) and the previous field was smaller than long, it could
lead to the whole union shifting position and offsets of the following
fields could change. It's also safer to align the size, too.

Let the 'size' parameter specify number of longs to be added and not number
of bytes. Note we assume a 64 bit architecture, which is the case for RHEL.

Upstream Status: RHEL only
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Donald Dutile authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Neil Horman <nhorman@redhat.com>
RH-Acked-by: Jonathan Toppins <jtoppins@redhat.com>
RH-Acked-by: Jiri Benc <jbenc@redhat.com>
RH-Acked-by: Prarit Bhargava <prarit@redhat.com>

Upstream status: RHEL only

rh_kabi: Indirect EXTEND macros so nesting of other macros will resolve.

Upstream Status: RHEL only
Suggested-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: Donald Dutile <ddutile@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Tony Camuso authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Prarit Bhargava <prarit@redhat.com>
RH-Acked-by: Jiri Benc <jbenc@redhat.com>

Upstream Status: RHEL only

Since this macro is intended to record the sizeof extension structs that
are dynamically allocated, using the structure dereference operator '->'
is a better choice, else the macro would have to be invoked with the
_name argument dereferenced as (*_name).

Also added a short note explaining that, unlike the other RH_KABI
macros that are invoked from within structs, this macro is invoked
outside a struct and therefore needs a semicolon termination.

Upstream Status: RHEL only
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Prarit Bhargava authored Feb 19, 2020 and Justin M. Forbes committed Aug 12, 2020

RH-Acked-by: Ivan Vecera <ivecera@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>
RH-Acked-by: Jiri Benc <jbenc@redhat.com>

Upstream: RHEL-only

As noted in the reviews, there are some areas of future work:

1) A further restriction on the access of the extended struct fields
would be to require the addition of an accessor function.
2) Additional macros to use RH_KABI_EXTEND fields.
3) Additional macros to mark extended struts' field for internal kernel
versus module use.

The RHEL7 code contains macros to extend kernel structs.  For example, the
RH_KABI_EXTEND() can be used to extend a struct when used appropriately.
This macro (and others similar to it) has a significant shortcoming as it
cannot be used in the case where a struct is known to allocate the struct
within a 3rd party module.  For example, in RHELX.0, suppose there exists
a struct,

struct in_kernel {
	int foo0;
};

and an exported function,

void in_kernel_set_foo(struct in_kernel *ink)
{
	...
	ink->foo0 = 0xBA5EBA11;
	...
}

Let's also suppose a struct in_kernel is statically defined within a 3rd
party module, or dynamically allocated as

	struct in_kernel *3rd_party_ink;
	...
	ink = kmalloc(sizeof(*3rd_party_ink), GFP_KERNEL);
	...

In RHELX.1, suppose the struct is expanded by

struct in_kernel {
	int foo0;
	RH_KABI_EXTEND(foo1)
};

and the exported function is modified as

void in_kernel_set_foo(struct in_kernel *ink)
{
	...
	ink->foo0 = 0xBA5EBA11;
	ink->foo1 = 0xBA5EBA11;
	...
}

The 3rd party module, compiled against RHELX.0, will not have allocated
memory for foo1, and in_kernel_set_foo() will reference garbage in memory.

To fix this problem, Jiri Benc came up with an great solution that should
be unified for all future RHELX.0 expansions of structs.  RHEL7 commit
e33a3c136b56 ("[net] introduce net_device_ops_extended") adds a size
parameter to net_device_ops that can be queried to validate memory
accesses.  In the patch, net_device_ops is expanded by embedding a
net_device_ops_extended struct and addig a size parameter.  The size
parameter is used to compare the offset of a parameter in the
net_device_ops_extended struct to the size of the struct at compile time,
and if valid, the memory access can be programmatically allowed to occur.

I have taken his idea and created several new standard macros that allow
structs to be expanded by embedding a new struct or by adding a pointer
to a new struct.

There are, however, some rules that must be followed when using these
new macros:

1.  The default name of the extended struct is ##name##_rh.  For example,
pci_dev_rh, device_rh, net_device_ops_rh, etc.
2.  _rh structs cannot be shrunk in size as such changes would break the
size & offset comparison.
3.  The size field _must_ be set at the spot of allocation for use.  Use of the
_rh fields without setting the size field via RH_KABI_SET_SIZE|_PTR() is
invalid in the kernel or in a 3rd party module.
4.  These new macros do not preclude expansions like

struct in_kernel_rh {
};

struct in_kernel {
	...
	RH_KABI_EXTEND(void *ptr1)
	RH_KABI_EXTEND(void *ptr2)
	RH_KABI_EXTEND(void *ptr3)
	RH_KABI_EXTEND(void *ptr4)
	RH_KABI_SIZE_AND_EXTEND_PTR(in_kernel)
};

These macros are generally intended for pre-KABI freeze use, however,
there may be cases where these macros can be used post-KABI freeze.
Due to the design of RH_KABI_EXTEND() which embeds __GENKSYMS__ care must
be taken when using RH_KABI_SIZE_AND_EXTEND|_PTR() post-KABI freeze to
ensure that structs are not embedded within another struct, verifying
offsets, etc.

Add RH_KABI_SIZE_AND_EXTEND(), RH_KABI_SIZE_AND_EXTEND_PTR(), and
other macros that allow for safe expansion of structs.

v2: Cleanup comments.
v3: Cleanup comments.

Upstream Status: RHEL only
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Jiri Benc <jbenc@redhat.com>

Dick Kennedy authored Feb 14, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <1525206184-20470-1-git-send-email-dkennedy@redhat.com>
Patchwork-id: 212089
O-Subject: [RHEL8 PATCH e-stor] Removing Obsolete hba pci-ids from rhel8.
Bugzilla: 1572321
RH-Acked-by: Chris Leech <cleech@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>

These adapters printed an Obsolete Unsupported message is rhel7. They
are being removed for rhel8

brew-id: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID^U948800


bugzilla: 1572321
tested on: rhel-storage-44 and on rhel-storage-07

RHEL Specific

Upstream Status: RHEL only
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Backport Notes: Simplify by filtering using pci_ids
-

Laura Abbott authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Author: Tomas Henzl <thenzl@redhat.com>
Date:   Thu Jan 31 16:54:51 2019 -0500

    [message] mptsas: pci-id table changes

    Message-id: <20190131165452.7562-3-thenzl@redhat.com>
    Patchwork-id: 239765
    O-Subject: [RHEL8 e-stor 2/3] mptsas: pci-id table changes
    Bugzilla: 1666730
RH-Acked-by: Jarod Wilson <jarod@redhat.com>
RH-Acked-by: Tony Camuso <tcamuso@redhat.com>
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>

    RHEL-only

    We want to provide this driver only for the virtualisation use case,
    so we remove all other entries from the pci-id table and add only the
    single entry needed for virtualisation.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Laura Abbott <labbott@redhat.com>

Laura Abbott authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Author: Tomas Henzl <thenzl@redhat.com>
Date:   Thu Jan 31 16:54:50 2019 -0500

    [message] mptsas: Taint kernel if mptsas is loaded

    Message-id: <20190131165452.7562-2-thenzl@redhat.com>
    Patchwork-id: 239764
    O-Subject: [RHEL8 e-stor 1/3] mptsas: Taint kernel if mptsas is loaded
    Bugzilla: 1666730
RH-Acked-by: Jarod Wilson <jarod@redhat.com>
RH-Acked-by: Tony Camuso <tcamuso@redhat.com>
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>

    RHEL-only

    We are only keeping it to ease developer transitions, we're not
    supporting it, so mark it as unsupported by tainting the kernel and
    issuing an impossible to misunderstand message to the log

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Laura Abbott <labbott@redhat.com>

Laura Abbott authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Author: Tomas Henzl <thenzl@redhat.com>
Date:   Thu Jan 10 16:11:44 2019 -0500

    [message] mptspi: pci-id table changes

    Message-id: <20190110161145.5117-3-thenzl@redhat.com>
    Patchwork-id: 237190
    O-Subject: [RHEL-8.0 e-stor 2/3] mptspi: pci-id table changes
    Bugzilla: 1651803
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>

    RHEL-only
    We want to provide this driver only for the virtualisation use case,
    so we remove all other entries from the pci-id table and add only the
    single entry needed for virtualisation.

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Laura Abbott <labbott@redhat.com>

Jeremy Cline authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <20190708192223.21890-1-jcline@redhat.com>
Patchwork-id: 266422
O-Subject: [ARK INTERNAL PATCH] qla2xxx: Remove PCI IDs of deprecated adapter
Bugzilla:
RH-Acked-by: Don Zickus <dzickus@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>

Commit ecc89f25

 ("scsi: qla2xxx: Add Device ID for ISP28XX")
introduced addition device IDs which broke the patch context.

    Message-id: <20180503234750.33648-1-hmadhani@redhat.com>
    Patchwork-id: 212501
    O-Subject: [RHEL 8 e-stor PATCH v2] qla2xxx: Remove PCI IDs of deprecated adapter
    Bugzilla: 1572233
RH-Acked-by: Tomas Henzl <thenzl@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>
RH-Acked-by: Tom Coughlan <coughlan@redhat.com>

    Bugzilla:
    ========    https://bugzilla.redhat.com/show_bug.cgi?id72233

    commit none

    Brewbuild:
    ==========    https://brewweb.engineering.redhat.com/brew/taskinfo?taskID977226



    Tetsing:
    =======    N/A. PCI IDs are removed as part of this patch

Signed-off-by: Himanshu Madhani <hmadhani@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Jeremy Cline <jcline@redhat.com>

Note: Simplified backport to just pci-ids

Chris Leech authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <20180503194032.1461134-1-cleech@redhat.com>
Patchwork-id: 212454
O-Subject: [RHEL8 PATCH e-stor] scsi: be2iscsi: remove unsupported device IDs
Bugzilla: 1574502
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Tom Coughlan <coughlan@redhat.com>
RH-Acked-by: Ewan Milne <emilne@redhat.com>

Bugzilla: 1574502
Upstream Status: RHEL Specific
Build Info: brew 15975638

BladeEngine 2 generation devices are deprecated in RHEL 7
and not supported in RHEL 8

Signed-off-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

be2iscsi: remove BE3 family support

Message-id: <1530890927-5792-1-git-send-email-mlombard@redhat.com>
Patchwork-id: 223576
O-Subject: [RHEL8 e-stor PATCH] be2iscsi: remove BE3 family support
Bugzilla: 1598366
RH-Acked-by: Tomas Henzl <thenzl@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>

BZ: https://bugzilla.redhat.com/show_bug.cgi?id98366
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID996775
Upstream: RHEL-only, they tried to mark BE3 as unsupported
          in upstream kernel but the patch has been rejected.
          See: https://marc.info/?l=linux-scsi&m2835991600881&w=2



Broadcom doesn't want to provide support for the BE3 device family
in RHEL8.

This patch removes the BE3's PCI-IDs.

Upstream Status: RHEL only
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Laura Abbott authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Author: Tomas Henzl <thenzl@redhat.com>
Date:   Thu Jan 10 16:11:43 2019 -0500

    [message] mptspi: Taint kernel if mptspi is loaded

    Message-id: <20190110161145.5117-2-thenzl@redhat.com>
    Patchwork-id: 237188
    O-Subject: [RHEL-8.0 e-stor 1/3] mptspi: Taint kernel if mptspi is loaded
    Bugzilla: 1651803
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>

    RHEL-only
    We are only keeping it to ease developer transitions, we're not
    supporting it, so mark it as unsupported by tainting the kernel and
    issuing an impossible to misunderstand message to the log

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Laura Abbott <labbott@redhat.com>

Joseph Szczypek authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <1524750809-43700-2-git-send-email-jszczype@redhat.com>
Patchwork-id: 211573
O-Subject: [RHEL8 e-stor PATCH 1/2] hpsa: remove old cciss-based smartarray pci ids
Bugzilla: 1471185
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Tomas Henzl <thenzl@redhat.com>

Per discussion with Microsemi, the old PCI IDs for smartarrays
originally used with the old cciss driver are not being
supported with RHEL8. They are also not supported with RHEL7.
Therefore the PCI IDs and the catch-all are being removed.

Acked-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only

Chad Dupuis authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <1524063895-23086-1-git-send-email-cdupuis@redhat.com>
Patchwork-id: 209742
O-Subject: [RHEL 8 e-stor PATCH] qla4xxx: Remove depricated PCI IDs from RHEL 8.
Bugzilla: 1518874
RH-Acked-by: Tomas Henzl <thenzl@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>

Bugzilla: 1518874

RHEL 8 specific

Brew build: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID822250



Three PCI device IDs are marked as deprecated in RHEL 7:

PCI_DEVICE_ID_QLOGIC_ISP8022
PCI_DEVICE_ID_QLOGIC_ISP8324
PCI_DEVICE_ID_QLOGIC_ISP8042

This patch removes them from the PCI table in RHEL 8 so the
qla4xxx driver will not bind to the hardware.

Upstream Status: RHEL only
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Raghava Aditya Renukunta authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <20180315040041.9449.8525.stgit@dhcp187-32.khw.lab.eng.bos.redhat.com>
Patchwork-id: 206793
O-Subject: [RHEL8 e-stor PATCH] scsi: aacraid: Remove depreciated device and vendor PCI id's
Bugzilla: 1495307
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Tomas Henzl <thenzl@redhat.com>

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id95307
Brew Info: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID552286


Upstream Status: N/A (RHEL 8 internal)
Tested: Code Review

Remove Vendor PCI ID and Device PCI ID of depreciated devices from
aacraid pci table, preventing these device from attaching to the aacraid
driver.

Upstream Status: RHEL only
Signed-off-by: Raghava Aditya Renukunta <rrenukun@redhat.com>
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Tomas Henzl authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <20180403143030.4971-2-thenzl@redhat.com>
Patchwork-id: 7432
O-Subject: [kernel team] [RHEL8 e-stor PATCH] megaraid_sas: remove deprecated pci-ids
Bugzilla: 1509329
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>

bz#1509329
brew - task_15594743

RH specific - remove EOL devices from the pci-id table
(devices to remove were selected by Broadcom)

Upstream Status: RHEL only
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Jeremy Cline authored Jan 02, 2020 and Justin M. Forbes committed Aug 12, 2020

Message-id: <20190708192032.20922-1-jcline@redhat.com>
Patchwork-id: 266421
O-Subject: [ARK INTERNAL PATCH] mpt*: remove certain deprecated pci-ids
Bugzilla:
RH-Acked-by: Don Zickus <dzickus@redhat.com>
RH-Acked-by: Jarod Wilson <jarod@redhat.com>

Commit 8f838450

 ("scsi: mpt3sas: Add support for NVMe Switch
Adapter") introduced a new PCI device ID which broke the patch context.

    Message-id: <20180403143030.4971-1-thenzl@redhat.com>
    Patchwork-id: 7431
    O-Subject: [kernel team] [RHEL8 e-stor PATCH] mpt*: remove certain deprecated pci-ids
    Bugzilla: 1511953
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Chris Leech <cleech@redhat.com>

    bz#1511953
    brew - task_15594743

    RH specific - remove EOL devices from the pci-id table
    (devices to remove were selected by Broadcom)

Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Upstream Status: RHEL only
Signed-off-by: Jeremy Cline <jcline@redhat.com>

Tomas Henzl authored Aug 09, 2018 and Justin M. Forbes committed Aug 12, 2020

Message-id: <e9a9812a-6a4c-a205-e66a-1d47de58306a@redhat.com>
Patchwork-id: 226423
O-Subject: [RHEL-8.0 V4 01/10] kernel: add SUPPORT_REMOVED kernel taint
Bugzilla: 1602033
RH-Acked-by: Maurizio Lombardi <mlombard@redhat.com>
RH-Acked-by: Jiri Benc <jbenc@redhat.com>
RH-Acked-by: Rob Evers <revers@redhat.com>

Upstream Status: RHEL only

rh_taint, pci : add information about removed hardware

Upstream Status: RHEL only
Signed-off-by: Herton R. Krzesinski <herton@redhat.com>

Don Zickus authored Mar 03, 2020 and Justin M. Forbes committed Aug 12, 2020

The intent of RH_DISABLE_DEPRECATED was to provide Red Hat a
simple way to disable drivers it did not want to support in RHEL.

As the config option was applied to more drivers and infra, it became
clear the option was being used for not only deprecating drivers (which
implied limited support) to disabling drivers (implying no support).

Using the word 'deprecated' seemed confusing in the second scenario.
Rename the option to be more generic and useable across more parts
of the kernel tree.

The new wording is RHEL_DIFFERENCES.

Upstream Status: RHEL only

pbrobinson authored Feb 26, 2020 and Justin M. Forbes committed Aug 12, 2020

This is a hack, but it's what the other distros currently use
for aarch64 with 4K pages so we'll do the same while upstream
decides what the best outcome is (which isn't this).

Upstream Status: RHEL only
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[Add a dependency on RHEL_DIFFERENCES]
Signed-off-by: Jeremy Cline <jcline@redhat.com>

Jeremy Cline authored Oct 30, 2019 and Justin M. Forbes committed Aug 12, 2020

Automatically lock down the kernel to LOCKDOWN_CONFIDENTIALITY_MAX if
the IPL secure flag is set.

Upstream Status: RHEL only
Suggested-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>

David Howells authored Sep 30, 2019 and Justin M. Forbes committed Aug 12, 2020

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 to lock down the kernel - which includes
requiring validly signed modules - if the kernel is secure-booted.

Upstream Status: RHEL only
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>

David Howells authored Feb 27, 2018 and Justin M. Forbes committed Aug 12, 2020

UEFI machines can be booted in Secure Boot mode.  Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.

Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.

Upstream Status: RHEL only
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org
[Rebased for context; efi_is_table_address was moved to arch/x86]
Signed-off-by: Jeremy Cline <jcline@redhat.com>

Jeremy Cline authored Sep 30, 2019 and Justin M. Forbes committed Aug 12, 2020

In order to automatically lock down kernels running on UEFI machines
booted in Secure Boot mode, expose the lock_kernel_down() hook.

Upstream Status: RHEL only
Signed-off-by: Jeremy Cline <jcline@redhat.com>