linux.git/include/linux, branch v4.14.301

perf: Add sample_flags to indicate the PMU-filled sample data

2022-12-08T10:16:32+00:00

[ Upstream commit 3aac580d5cc3001ca1627725b3b61edb529f341d ]

On some platforms, some data e.g., timestamps, can be retrieved from
the PMU driver. Usually, the data from the PMU driver is more accurate.
The current perf kernel should output the PMU-filled sample data if
it's available.

To check the availability of the PMU-filled sample data, the current
perf kernel initializes the related fields in the
perf_sample_data_init(). When outputting a sample, the perf checks
whether the field is updated by the PMU driver. If yes, the updated
value will be output. If not, the perf uses an SW way to calculate the
value or just outputs the initialized value if an SW way is unavailable
either.

With more and more data being provided by the PMU driver, more fields
has to be initialized in the perf_sample_data_init(). That will
increase the number of cache lines touched in perf_sample_data_init()
and be harmful to the performance.

Add new "sample_flags" to indicate the PMU-filled sample data. The PMU
driver should set the corresponding PERF_SAMPLE_ flag when the field is
updated. The initialization of the corresponding field is not required
anymore. The following patches will make use of it and remove the
corresponding fields from the perf_sample_data_init(), which will
further minimize the number of cache lines touched.

Only clear the sample flags that have already been done by the PMU
driver in the perf_prepare_sample() for the PERF_RECORD_SAMPLE. For the
other PERF_RECORD_ event type, the sample data is not available.

Suggested-by: Peter Zijlstra (Intel) 
Signed-off-by: Kan Liang 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/r/20220901130959.1285717-2-kan.liang@linux.intel.com
Signed-off-by: Sasha Levin

linux/bits.h: make BIT(), GENMASK(), and friends available in assembly

2022-11-10T14:47:24+00:00

commit 95b980d62d52c4c1768ee719e8db3efe27ef52b2 upstream.

BIT(),  GENMASK(), etc. are useful to define register bits of hardware.
However, low-level code is often written in assembly, where they are
not available due to the hard-coded 1UL, 0UL.

In fact, in-kernel headers such as arch/arm64/include/asm/sysreg.h
use _BITUL() instead of BIT() so that the register bit macros are
available in assembly.

Using macros in include/uapi/linux/const.h have two reasons:

[1] For use in uapi headers
  We should use underscore-prefixed variants for user-space.

[2] For use in assembly code
  Since _BITUL() uses UL(1) instead of 1UL, it can be used as an
  alternative of BIT().

For [2], it is pretty easy to change BIT() etc. for use in assembly.

This allows to replace _BUTUL() in kernel-space headers with BIT().

Link: http://lkml.kernel.org/r/20190609153941.17249-1-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada 
Cc: Catalin Marinas 
Cc: Christian Borntraeger 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Vineet Gupta 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

linux/const.h: move UL() macro to include/linux/const.h

2022-11-10T14:47:24+00:00

commit 2dd8a62c647691161a2346546834262597739872 upstream.

ARM, ARM64 and UniCore32 duplicate the definition of UL():

  #define UL(x) _AC(x, UL)

This is not actually arch-specific, so it will be useful to move it to a
common header.  Currently, we only have the uapi variant for
linux/const.h, so I am creating include/linux/const.h.

I also added _UL(), _ULL() and ULL() because _AC() is mostly used in
the form either _AC(..., UL) or _AC(..., ULL).  I expect they will be
replaced in follow-up cleanups.  The underscore-prefixed ones should
be used for exported headers.

Link: http://lkml.kernel.org/r/1519301715-31798-4-git-send-email-yamada.masahiro@socionext.com
Signed-off-by: Masahiro Yamada 
Acked-by: Guan Xuetao 
Acked-by: Catalin Marinas 
Acked-by: Russell King 
Cc: David Howells 
Cc: Geert Uytterhoeven 
Cc: Will Deacon 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

efi: random: reduce seed size to 32 bytes

2022-11-10T14:47:23+00:00

commit 161a438d730dade2ba2b1bf8785f0759aba4ca5f upstream.

We no longer need at least 64 bytes of random seed to permit the early
crng init to complete. The RNG is now based on Blake2s, so reduce the
EFI seed size to the Blake2s hash size, which is sufficient for our
purposes.

While at it, drop the READ_ONCE(), which was supposed to prevent size
from being evaluated after seed was unmapped. However, this cannot
actually happen, so READ_ONCE() is unnecessary here.

Cc:  # v4.14+
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jason A. Donenfeld 
Acked-by: Ilias Apalodimas 
Signed-off-by: Greg Kroah-Hartman

x86/bugs: Report AMD retbleed vulnerability

2022-11-01T18:14:44+00:00

commit 6b80b59b3555706508008f1f127b5412c89c7fd8 upstream.

Report that AMD x86 CPUs are vulnerable to the RETBleed (Arbitrary
Speculative Code Execution with Return Instructions) attack.

  [peterz: add hygon]
  [kim: invert parity; fam15h]

Co-developed-by: Kim Phillips 
Signed-off-by: Kim Phillips 
Signed-off-by: Alexandre Chartre 
Signed-off-by: Peter Zijlstra (Intel) 
Signed-off-by: Borislav Petkov 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thadeu Lima de Souza Cascardo 
[ bp: Adjust context ]
Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Greg Kroah-Hartman

x86/cpu: Add a steppings field to struct x86_cpu_id

2022-11-01T18:14:44+00:00

commit e9d7144597b10ff13ff2264c059f7d4a7fbc89ac upstream

Intel uses the same family/model for several CPUs. Sometimes the
stepping must be checked to tell them apart.

On x86 there can be at most 16 steppings. Add a steppings bitmask to
x86_cpu_id and a X86_MATCH_VENDOR_FAMILY_MODEL_STEPPING_FEATURE macro
and support for matching against family/model/stepping.

 [ bp: Massage.
   tglx: Lightweight variant for backporting ]

Signed-off-by: Mark Gross 
Signed-off-by: Borislav Petkov 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Tony Luck 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Greg Kroah-Hartman

x86/devicetable: Move x86 specific macro out of generic code

2022-11-01T18:14:44+00:00

commit ba5bade4cc0d2013cdf5634dae554693c968a090 upstream

There is no reason that this gunk is in a generic header file. The wildcard
defines need to stay as they are required by file2alias.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Borislav Petkov 
Reviewed-by: Greg Kroah-Hartman 
Link: https://lkml.kernel.org/r/20200320131508.736205164@linutronix.de
Signed-off-by: Greg Kroah-Hartman

Revert "x86/cpu: Add a steppings field to struct x86_cpu_id"

2022-11-01T18:14:44+00:00

This reverts commit ae585de4296413ae4bbb8f2ac09faa38ff78f4cd.

This is commit e9d7144597b10ff13ff2264c059f7d4a7fbc89ac upstream. Reverting this
commit makes the following patches apply cleanly. This patch is then reapplied.

Signed-off-by: Suraj Jitindar Singh 
Signed-off-by: Greg Kroah-Hartman

iommu/iova: Fix module config properly

2022-10-26T11:17:08+00:00

[ Upstream commit 4f58330fcc8482aa90674e1f40f601e82f18ed4a ]

IOMMU_IOVA is intended to be an optional library for users to select as
and when they desire. Since it can be a module now, this means that
built-in code which has chosen not to select it should not fail to link
if it happens to have selected as a module by someone else. Replace
IS_ENABLED() with IS_REACHABLE() to do the right thing.

CC: Thierry Reding 
Reported-by: John Garry 
Fixes: 15bbdec3931e ("iommu: Make the iova library a module")
Signed-off-by: Robin Murphy 
Reviewed-by: Thierry Reding 
Link: https://lore.kernel.org/r/548c2f683ca379aface59639a8f0cccc3a1ac050.1663069227.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin

ata: fix ata_id_has_dipm()

2022-10-26T11:17:05+00:00

[ Upstream commit 630624cb1b5826d753ac8e01a0e42de43d66dedf ]

ACS-5 section
7.13.6.36 Word 78: Serial ATA features supported
states that:

If word 76 is not 0000h or FFFFh, word 78 reports the features supported
by the device. If this word is not supported, the word shall be cleared
to zero.

(This text also exists in really old ACS standards, e.g. ACS-3.)

The problem with ata_id_has_dipm() is that the while it performs a
check against 0 and 0xffff, it performs the check against
ATA_ID_FEATURE_SUPP (word 78), the same word where the feature bit
is stored.

Fix this by performing the check against ATA_ID_SATA_CAPABILITY
(word 76), like required by the spec. The feature bit check itself
is of course still performed against ATA_ID_FEATURE_SUPP (word 78).

Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros
(which already have this check), thus making it more likely that the
next ATA_ID_FEATURE_SUPP macro that is added will include this check.

Fixes: ca77329fb713 ("[libata] Link power management infrastructure")
Signed-off-by: Niklas Cassel 
Signed-off-by: Damien Le Moal 
Signed-off-by: Sasha Levin