The workflow for the integration of the gitlab-ci submodule has changed.
Updated the gitlab-ci yaml file to use the new workflow and also updated
the CI to the current revision.

Note: The name of linux-guf was changed to linux-seconorth for the 5.15
kernel.

The VDD_3P3 should not be disabled, even not logically. Thus prevent
this by fixing the typo regulator_always_on to regulator-always-on.

Add support for the Garz& Fricke NALLINO platform. The NALLINO platform
is based on an NXP i.MX6 ULL. It includes support for a parallel RBG
Display, I2C Touch, RS232, RS485, microSD-Card.

Add support for the Garz & Fricke SANTINO-LT platform. The SANTINO-LT
platform is based on an NXP i.MX6 Solo or DualLite. It includes support
for a parallel RBG Display, CAN, Audio, I2C Touch, RS232, RS485,
microSD-Card.

Add support for the Garz& Fricke SANTARO platform. The SANTARO platform
is based on an NXP i.MX6 Solo, DualLite, Dual or Quad. It includes
support for an LVDS Display, Audio, RTC, Temperature Sensor, I2C Touch,
RS232, RS485, SD-Card.

Add support for the Garz& Fricke SANTOKA platform. The SANTOKA platform
is based on an NXP i.MX6 Solo, DualLite, Dual, Quad or QuadPlus. It
includes support for an LVDS Display, CAN, Audio, Temperature Sensor,
PCIe, RTC, I2C Touch, RS232, RS485, SD-Card and USB.

 Add support for the Garz& Fricke SANTINO platform. The SANTINO platform
 is based on an NXP i.MX6 Solo or DuaslLite. It includes support for an
 RGB Display, I2C Touch, RS232, RS485, SD-Cards and USB.

Add create Garz & Fricke directory below arch/arm/boot/dts to keep the
Garz & Fricke specific files separated. This is not the "common"
mainline approach for ARM dts definitions, however it is the practice
for ARM64 platform.

Add the common imx6qdl-san.dtsi include file that is common for all garz
& Fricke SAN* platforms. Later commits will add those separately.

* Add aliases for all platforms
* Add default std-out
* Add common audio parts like audio amplifier, audio-codec-clock,
  sgtl5000, ssi
* Add backlight
* Add gfplatdetect
* Add common regulators
* Configure AUDMUX for different platforms. The actual routing is done
  in the platform definition
* Add CAN
* Add common clock definition for the IPU
* Add Fast Ethernet Controller (FEC)
* Add I2C1, I2C2 and I2C3
* Add all pinctrl entries.
* Add UARTs
* Add USB ports
* Add USDHC
* Add watchdog reset pin

Felix Gerking authored 3 years ago and Clemens Terasa committed 3 years ago

BCS 746-000016

Jonas Höppner authored 3 years ago and Clemens Terasa committed 3 years ago

As per request form the marketing department, add a neutral Garz &
Fricke boot splash. This also fits into the Garz & Fricke group.

Also add a Flash-N-Go System logo.

BCS 746-000275
BCS 746-000468

This patchset adds Garz & Fricke specific version info to the mainline
kernel. It adds information to /proc/cpuinfo, exports symbols to be used
by a separate Garz & Fricke versioning module and exports the
ATAG_Version (used for the Flash-N-Go Boot bootloader version) to the
device tree.

On previous implementations we introduced the board revision and the
bootloader revision in the /proc/cpuinfo. Because of legacy consumers
namely the install script, the demos and maybe more tools, we decided to
add those also to this more mainline kernel.

The detection itself should come from a platform-detection module and
may be built out of kernel.

Add the variables for the board revision and the Flash-N-Go Boot
bootloader version, export them and show the contents in the
/proc/cpuinfo entry.

For a platform detection module more information of the actual hardware
is needed. Specifically the mxc_cpu_type and the iMX SoC revision
information is needed.

Avoid exporting the __mxc_cpu_type though, as it should not be
overwritten by an external module.

Thus add a new function mxc_get_cpu_type and export both, the newly
added function and the imx_get_soc_revision.

The modification of the machine name is not possible if the machine
name is not exported.  Thus export the machine_name variable.

By default the machine name comes from ATAGS or the machines_desc
structure that most often is created by the {DT_}MACHINE_START macros.

For our custom boards, however, we want to set the machine name
externally from a module. The alternative would be to creta a custom
board-* oder mach-* .c file in arch/arm/mach-imx/. This, however, would copy
most of the sensible platform code, which I regard as disencouraged.

A "platform-detection" module would be a clean and nicely separated
solution.

The ATAGS have various tags useful to determine platform specific data
already acquired from or generated by the bootloader.
In this case it is the revision tag that the bootloader might fill in
the ATAGS structure.

In the G&F case and using the Flash-N-Go Boot bootloader the bootloader
version is propagated in the ATAGS_REVISION tag.

To be able to handle this later after the ATAGS are destroyed parse
the ATAG_REVISION and add it to a atag-revision entry in the device
tree.

Carsten Behling authored 4 years ago and Clemens Terasa committed 3 years ago

On Garz & Fricke linux ports for historic and legacy reasons a
different virtual kernel address offset is being used.

Set the textofs from 0x00008000 to 0x00010000 and do so as well for the
KERNEL_RAM_VADDR.

TODO: Perhaps add a Garz & Fricke specific config or preprocessor
variable.

Jonas Höppner authored 4 years ago and Clemens Terasa committed 3 years ago

The lagacyfb_depth was set to 16 by default, but we want 32 to have all
colors of a 24bit display also during framebuffer access.

BCS 746-000038

This introduces a new panel driver called panel-dt for panels defined in
the device tree.
The goal is to create a panel driver similar to the panel-simple but
introducing more device tree features, and make the definition via
device tree definition mandatory, instead of overriding an exiting
pre-defined panel.
This would enable us to define most of the functionalities in the device
tree.

This approach has already been discussed in
https://patchwork.kernel.org/patch/10842593/

 but was not considered to
be valuable for the mainline linux kernel.

For some users and for us, however, this might be very helpful.

The question is still open, if the changes are better suited in the
panel-simple and perhaps introducing another variation, similar to the
panel-simple-dsi variant or in a separate file but this uses the latter
approach.

Steps taken:
* Introduce the new panel-dt file, copied from panel-simple.c.
  Set the license to GPLv2.
* Add the panel-dt driver to the Kconfig and conditionally build.
* Remove the panel descriptions as well as the DSI interface.
  With the removal of the  DSI interace the module can be initialized by
  a simple module_platform_driver() call.
* Remove all timings and modes.
* Also rewrite the probe routine to require the panel-timings entry
  similar to the panel-lvds case.
* Get the panel properties form the device tree instead of the
  simple-panel hard-coded way. Import the delays, dimensions (in mm),
  the bus-format and -flags and bits-per-color.
* Add the device tree bindings documentation for the panel-dt driver.
  Regression: I was not able to test it with `make dt_binding_check` or
  `make dtbs_check` as per Documentation/devicetree/writing-schema.md.
* Add the support for the special LVDS SEL6_8 GPIO that on some displays
  enables switches between 18 and 24 bit modes.
  This is somewhat Garz & Fricke specific.
* Regression: The "guf," compatible prefix is not yet defined in
  Documentation/devicetree/bindings/vendor-prefixes.yaml
* In recent kernel the rotation property was introduced in the panel
  device tree definitions and the panel-simple driver.
  Do the same for panel-dt and add the rotation information.
  However, I currently see no effect, but Weston should use this property
  since version 9.0.0
* Preliminary uncomment the drm_connector_set_panel_orientation call
  in the get_modes implementation.
* The bus flags can be supplied by the similar enum display_flags. the
  display_flags are part of the videomode and can be converted to
  bus_flags by using the drm_bus_flags_from_videomode() function.  By
  using this in the panel-dt driver we get the possibility to use the
  polarity settings like hsync-active, vsync-active, de-active,
  pixelclk-active and syncclk-active.

  BCS 746-000430
  BCS 746-000415
  BCS 746-000415

Signed-off-by: Clemens Terasa <clemens.terasa@garz-fricke.com>

Norman Stetter authored 4 years ago and Clemens Terasa committed 3 years ago

* pull in the PF1550 PMIC driver from linux-fscl at commit
f2c1392ff3473a396e4d177ff5ad368b9d6cd211

Add the DRM_BUS_FLAG_SYNC_DRIVE_{POS,NEG}EDGE as valid bus flag setting.

Let's assume following function call order form a panel driver:
of_parse_display_timing() -> videomode_from_timing() ->
drm_bus_flags_from_videomode() and let's assume the result will end up
as bus_flags in the parallel-display driver.

The of_parse_display_timing() will set the DISPLAY_FLAGS_SYNC_*
flags either when given explicitly using the "syncclk-active" device
tree property or implicitly when the "pixelclk-active" property is being
used.

This results in the DRM_BUS_FLAG_SYNC_DRIVE_{POS,NEG}EDGE being set. So
it is necessary to include the DRM_BUS_FLAG_SYNC_DRIVE_{POS,NEG}EDGE in
the validity check as well.

BCS 746-000430

Jonas Höppner authored 3 years ago and Clemens Terasa committed 3 years ago

Integrate software implementation for mark and space from guf mdb driver.
Rewrite most of the code:
 Use controller_parity from the uart register
 Use available flags instead of new enum.
 Resort some code to remove dupplicated code snippets.
 Rewrite logic, more readable.
 Move mark and space parity to inline functions
 Disable DMA when CMSPAR is set, still port DMA needs to be disable to
 always work, as disable DMA after open (when setting CMSPAR via ioctl)
 is not implemented. Close and reopen after setting the bit does work.

 Also cleanup the reconfiguration of ODD/EVEN during TX, as RX lost
 bytes in the mdb driver variant. Now the rx_interrupt routine is called
 until all buffers are empty before disalbe RX and change ODD/EVEN parity.
 This way the received bytes could be mapped to the parity config used
 during rx. Still a short moment RX is disabled which could lead to
 missed bits.

 Theres also a busy wait until TX queues are empty, which could probably
 lead to high system load on slow datarates, as this might wait one byte
 long.

BCS 746-000322

Stolen from by https://lore.kernel.org/linux-arm-kernel/1397544101-18135-6-git-send-email-wens@csie.org/

Add device tree support for the rfkil-gpio driver.
Do not use the "new" gpio lookup from the same patchset.

Carsten Behling authored 4 years ago and Clemens Terasa committed 3 years ago

It is good practice to show the world the provider of a kernel build.
For Garz & Fricke build we always used "-guf" do to here as well.

Link: https://lore.kernel.org/r/20220314112743.029192918@linuxfoundation.org


Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Ron Economos <re@w6rz.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 95932ab2ea07b79cdb33121e2f40ccda9e6a73b5 upstream.

Commit e2ae38cf3d91 ("vhost: fix hung thread due to erroneous iotlb
entries") tries to reject the IOTLB message whose size is zero. But
the size is not necessarily meaningful, one example is the batching
hint, so the commit breaks that.

Fixing this be reject zero size message only if the message is used to
update/invalidate the IOTLB.

Fixes: e2ae38cf3d91 ("vhost: fix hung thread due to erroneous iotlb entries")
Reported-by: Eli Cohen <elic@nvidia.com>
Cc: Anirudh Rayabharam <mail@anirudhrb.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/r/20220310075211.4801-1-jasowang@redhat.com


Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Eli Cohen <elic@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 2566a89b which is
commit a2614140dc0f467a83aa3bb4b6ee2d6480a76202 upstream.

The above change depends on upstream commit 0faf890f ("net: dsa:
drop rtnl_lock from dsa_slave_switchdev_event_work"), which is not
present in linux-5.15.y. Without that change, waiting for the switchdev
workqueue causes deadlocks on the rtnl_mutex.

Backporting the dependency commit isn't trivial/desirable, since it
requires that the following dependencies of the dependency are also
backported:

df405910 net: dsa: sja1105: wait for dynamic config command completion on writes too
eb016afd net: dsa: sja1105: serialize access to the dynamic config interface
2468346c net: mscc: ocelot: serialize access to the MAC table
f7eb4a1c net: dsa: b53: serialize access to the ARL table
cf231b43 net: dsa: lantiq_gswip: serialize access to the PCE registers
338a3a47 net: dsa: introduce locking for the address lists on CPU and DSA ports

and then this bugfix on top:

8940e6b669ca ("net: dsa: avoid call to __dev_set_promiscuity() while rtnl_mutex isn't held")

Reported-by: Daniel Suchy <danny@danysek.cz>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b81e0c23 upstream.

Drop various include not actually used in genhd.h itself, and
move the remaning includes closer together.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/20210920123328.1399408-15-hch@lst.de


Signed-off-by: Jens Axboe <axboe@kernel.dk>
Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com&gt;a>
Reported-by: "H. Nikolaus Schaller" <hns@goldelico.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: "Maciej W. Rozycki" <macro@orcam.me.uk>
[ resolves MIPS build failure by luck, root cause needs to be fixed in
  Linus's tree properly, but this is needed for now to fix the build - gregkh ]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 74583f1b92cb3bbba1a3741cea237545c56f506c upstream.

Commit 67d96729 ("riscv: Update Canaan Kendryte K210 device tree")
incorrectly removed two entries from the PLIC interrupt-controller node's
interrupts-extended property.

The PLIC driver cannot know the mapping between hart contexts and hart ids,
so this information has to be provided by device tree, as specified by the
PLIC device tree binding.

The PLIC driver uses the interrupts-extended property, and initializes the
hart context registers in the exact same order as provided by the
interrupts-extended property.

In other words, if we don't specify the S-mode interrupts, the PLIC driver
will simply initialize the hart0 S-mode hart context with the hart1 M-mode
configuration. It is therefore essential to specify the S-mode IRQs even
though the system itself will only ever be running in M-mode.

Re-add the S-mode interrupts, so that we get working IRQs on hart1 again.

Cc: <stable@vger.kernel.org>
Fixes: 67d96729 ("riscv: Update Canaan Kendryte K210 device tree")
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e6f55120c7eccf6f9323bb681632e23cbcb3f3c upstream.

On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout
that doesn't match what the spec recommends. With a single active
pipe that is not going to be a problem, but with multiple pipes
active skl_commit_modeset_enables() goes into an infinite loop
since it can't figure out any order in which it can commit the
pipes without causing DBUF overlaps between the planes.

We'd need some kind of extra DBUF defrag stage in between to
make the transition possible. But that is clearly way too complex
a solution, so in the name of simplicity let's just sanitize the
DBUF state by simply turning off all planes when we detect a
pipe encroaching on its neighbours' DBUF slices. We only have
to disable the primary planes as all other planes should have
already been disabled (if they somehow were enabled) by
earlier sanitization steps.

And for good measure let's also sanitize in case the DBUF
allocations of the pipes already seem to overlap each other.

Cc: <stable@vger.kernel.org> # v5.14+
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762


Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com


Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
(cherry picked from commit 15512021eb3975a8c2366e3883337e252bb0eee5)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d96b34248c2f4ea8cd09286090f2f6f77102eaab upstream.

We don't allow send and balance/relocation to run in parallel in order
to prevent send failing or silently producing some bad stream. This is
because while send is using an extent (specially metadata) or about to
read a metadata extent and expecting it belongs to a specific parent
node, relocation can run, the transaction used for the relocation is
committed and the extent gets reallocated while send is still using the
extent, so it ends up with a different content than expected. This can
result in just failing to read a metadata extent due to failure of the
validation checks (parent transid, level, etc), failure to find a
backreference for a data extent, and other unexpected failures. Besides
reallocation, there's also a similar problem of an extent getting
discarded when it's unpinned after the transaction used for block group
relocation is committed.

The restriction between balance and send was added in commit 9e967495
("Btrfs: prevent send failures and crashes due to concurrent relocation"),
kernel 5.3, while the more general restriction between send and relocation
was added in commit 1cea5cf0 ("btrfs: ensure relocation never runs
while we have send operations running"), kernel 5.14.

Both send and relocation can be very long running operations. Relocation
because it has to do a lot of IO and expensive backreference lookups in
case there are many snapshots, and send due to read IO when operating on
very large trees. This makes it inconvenient for users and tools to deal
with scheduling both operations.

For zoned filesystem we also have automatic block group relocation, so
send can fail with -EAGAIN when users least expect it or send can end up
delaying the block group relocation for too long. In the future we might
also get the automatic block group relocation for non zoned filesystems.

This change makes it possible for send and relocation to run in parallel.
This is achieved the following way:

1) For all tree searches, send acquires a read lock on the commit root
   semaphore;

2) After each tree search, and before releasing the commit root semaphore,
   the leaf is cloned and placed in the search path (struct btrfs_path);

3) After releasing the commit root semaphore, the changed_cb() callback
   is invoked, which operates on the leaf and writes commands to the pipe
   (or file in case send/receive is not used with a pipe). It's important
   here to not hold a lock on the commit root semaphore, because if we did
   we could deadlock when sending and receiving to the same filesystem
   using a pipe - the send task blocks on the pipe because it's full, the
   receive task, which is the only consumer of the pipe, triggers a
   transaction commit when attempting to create a subvolume or reserve
   space for a write operation for example, but the transaction commit
   blocks trying to write lock the commit root semaphore, resulting in a
   deadlock;

4) Before moving to the next key, or advancing to the next change in case
   of an incremental send, check if a transaction used for relocation was
   committed (or is about to finish its commit). If so, release the search
   path(s) and restart the search, to where we were before, so that we
   don't operate on stale extent buffers. The search restarts are always
   possible because both the send and parent roots are RO, and no one can
   add, remove of update keys (change their offset) in RO trees - the
   only exception is deduplication, but that is still not allowed to run
   in parallel with send;

5) Periodically check if there is contention on the commit root semaphore,
   which means there is a transaction commit trying to write lock it, and
   release the semaphore and reschedule if there is contention, so as to
   avoid causing any significant delays to transaction commits.

This leaves some room for optimizations for send to have less path
releases and re searching the trees when there's relocation running, but
for now it's kept simple as it performs quite well (on very large trees
with resulting send streams in the order of a few hundred gigabytes).

Test case btrfs/187, from fstests, stresses relocation, send and
deduplication attempting to run in parallel, but without verifying if send
succeeds and if it produces correct streams. A new test case will be added
that exercises relocation happening in parallel with send and then checks
that send succeeds and the resulting streams are correct.

A final note is that for now this still leaves the mutual exclusion
between send operations and deduplication on files belonging to a root
used by send operations. A solution for that will be slightly more complex
but it will eventually be built on top of this change.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3755d35ee1d2454b20b8a1e20d790e56201678a4 upstream.

As reported in [1], DRM_PANEL_EDP depends on DRM_DP_HELPER. Select
the option to fix the build failure. The error message is shown
below.

  arm-linux-gnueabihf-ld: drivers/gpu/drm/panel/panel-edp.o: in function
    `panel_edp_probe': panel-edp.c:(.text+0xb74): undefined reference to
    `drm_panel_dp_aux_backlight'
  make[1]: *** [/builds/linux/Makefile:1222: vmlinux] Error 1

The issue has been reported before, when DisplayPort helpers were
hidden behind the option CONFIG_DRM_KMS_HELPER. [2]

v2:
	* fix and expand commit description (Arnd)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 9d6366e7 ("drm: fb_helper: improve CONFIG_FB dependency")
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://lore.kernel.org/dri-devel/CA+G9fYvN0NyaVkRQmA1O6rX7H8PPaZrUAD7=RDy33QY9rUU-9g@mail.gmail.com/ # [1]
Link: https://lore.kernel.org/all/20211117062704.14671-1-rdunlap@infradead.org/ # [2]
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220203093922.20754-1-tzimmermann@suse.de


Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a365a65f9ca1ceb9cf1ac29db4a4f51df7c507ad upstream.

Since kprobe_int3_handler() is called in do_int3(), probing do_int3()
can cause a breakpoint recursion and crash the kernel. Therefore,
do_int3() should be marked as NOKPROBE_SYMBOL.

Fixes: 21e28290 ("x86/traps: Split int3 handler up")
Signed-off-by: Li Huafei <lihuafei1@huawei.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20220310120915.63349-1-lihuafei1@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 08999b2489b4c9b939d7483dbd03702ee4576d96 upstream.

There is a limited amount of SGX memory (EPC) on each system.  When that
memory is used up, SGX has its own swapping mechanism which is similar
in concept but totally separate from the core mm/* code.  Instead of
swapping to disk, SGX swaps from EPC to normal RAM.  That normal RAM
comes from a shared memory pseudo-file and can itself be swapped by the
core mm code.  There is a hierarchy like this:

	EPC <-> shmem <-> disk

After data is swapped back in from shmem to EPC, the shmem backing
storage needs to be freed.  Currently, the backing shmem is not freed.
This effectively wastes the shmem while the enclave is running.  The
memory is recovered when the enclave is destroyed and the backing
storage freed.

Sort this out by freeing memory with shmem_truncate_range(), as soon as
a page is faulted back to the EPC.  In addition, free the memory for
PCMD pages as soon as all PCMD's in a page have been marked as unused
by zeroing its contents.

Cc: stable@vger.kernel.org
Fixes: 1728ab54 ("x86/sgx: Add a page reclaimer")
Reported-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lkml.kernel.org/r/20220303223859.273187-1-jarkko@kernel.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 445c1470b6ef96440e7cfc42dfc160f5004fd149 upstream.

The x86 boot documentation describes the setup_indirect structures and
how they are used. Only one of the two functions in ioremap.c that needed
to be modified to be aware of the introduction of setup_indirect
functionality was updated. Adds comparable support to the other function
where it was missing.

Fixes: b3c72fc9 ("x86/boot: Introduce setup_indirect")
Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1645668456-22036-3-git-send-email-ross.philipson@oracle.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7228918b34615ef6317edcd9a058a057bc54aa32 upstream.

As documented, the setup_indirect structure is nested inside
the setup_data structures in the setup_data list. The code currently
accesses the fields inside the setup_indirect structure but only
the sizeof(struct setup_data) is being memremapped. No crash
occurred but this is just due to how the area is remapped under the
covers.

Properly memremap both the setup_data and setup_indirect structures
in these cases before accessing them.

Fixes: b3c72fc9 ("x86/boot: Introduce setup_indirect")
Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1645668456-22036-2-git-send-email-ross.philipson@oracle.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4edc0760412b0c4ecefc7e02cb855b310b122825 upstream.

watch_queue_clear() has a comment stating that setting ->defunct to true
preventing new additions as well as preventing notifications.  Whilst
the latter is true, the first bit is superfluous since at the time this
function is called, the pipe cannot be accessed to add new event
sources.

Remove the "new additions" bit from the comment.

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2ed147f015af2b48f41c6f0b6746aa9ea85c19f3 upstream.

There's nothing to synchronise post_one_notification() versus
pipe_read().  Whilst posting is done under pipe->rd_wait.lock, the
reader only takes pipe->mutex which cannot bar notification posting as
that may need to be made from contexts that cannot sleep.

Fix this by setting pipe->head with a barrier in post_one_notification()
and reading pipe->head with a barrier in pipe_read().

If that's not sufficient, the rd_wait.lock will need to be taken,
possibly in a ->confirm() op so that it only applies to notifications.
The lock would, however, have to be dropped before copy_page_to_iter()
is invoked.

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ea1a0124b6da246b5bc8c66cddaafd36acf3ecb upstream.

Free the watch_queue note allocation bitmap when the watch_queue is
destroyed.

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b4c0371928c17af03e8397ac842346624017ce6 upstream.

Currently, watch_queue_set_size() sets the number of notes available in
wqueue->nr_notes according to the number of notes allocated, but sets
the size of the bitmap to the unrounded number of notes originally asked
for.

Fix this by setting the bitmap size to the number of notes we're
actually going to make available (ie. the number allocated).

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96a4d8912b28451cd62825fd7caa0e66e091d938 upstream.

The pipe ring size must always be a power of 2 as the head and tail
pointers are masked off by AND'ing with the size of the ring - 1.
watch_queue_set_size(), however, lets you specify any number of notes
between 1 and 511.  This number is passed through to pipe_resize_ring()
without checking/forcing its alignment.

Fix this by rounding the number of slots required up to the nearest
power of two.  The request is meant to guarantee that at least that many
notifications can be generated before the queue is full, so rounding
down isn't an option, but, alternatively, it may be better to give an
error if we aren't allowed to allocate that much ring space.

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c1853fbadcba1497f4907971e7107888e0714c81 upstream.

When a pipe ring descriptor points to a notification message, the
refcount on the backing page is incremented by the generic get function,
but the release function, which marks the bitmap, doesn't drop the page
ref.

Fix this by calling generic_pipe_buf_release() at the end of
watch_queue_pipe_buf_release().

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db8facfc9fafacefe8a835416a6b77c838088f8b upstream.

In free_pipe_info(), free the watchqueue state after clearing the pipe
ring as each pipe ring descriptor has a release function, and in the
case of a notification message, this is watch_queue_pipe_buf_release()
which tries to mark the allocation bitmap that was previously released.

Fix this by moving the put of the pipe's ref on the watch queue to after
the ring has been cleared.  We still need to call watch_queue_clear()
before doing that to make sure that the pipe is disconnected from any
notification sources first.

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c993ee0f9f81caf5767a50d1faeba39a0dc82af2 upstream.

In watch_queue_set_filter(), there are a couple of places where we check
that the filter type value does not exceed what the type_filter bitmap
can hold.  One place calculates the number of bits by:

   if (tf[i].type >= sizeof(wfilter->type_filter) * 8)

which is fine, but the second does:

   if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)

which is not.  This can lead to a couple of out-of-bounds writes due to
a too-large type:

 (1) __set_bit() on wfilter->type_filter
 (2) Writing more elements in wfilter->filters[] than we allocated.

Fix this by just using the proper WATCH_TYPE__NR instead, which is the
number of types we actually know about.

The bug may cause an oops looking something like:

  BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740
  Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611
  ...
  Call Trace:
   <TASK>
   dump_stack_lvl+0x45/0x59
   print_address_description.constprop.0+0x1f/0x150
   ...
   kasan_report.cold+0x7f/0x11b
   ...
   watch_queue_set_filter+0x659/0x740
   ...
   __x64_sys_ioctl+0x127/0x190
   do_syscall_64+0x43/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

  Allocated by task 611:
   kasan_save_stack+0x1e/0x40
   __kasan_kmalloc+0x81/0xa0
   watch_queue_set_filter+0x23a/0x740
   __x64_sys_ioctl+0x127/0x190
   do_syscall_64+0x43/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae

  The buggy address belongs to the object at ffff88800d2c66a0
   which belongs to the cache kmalloc-32 of size 32
  The buggy address is located 28 bytes inside of
   32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)

Fixes: c73be61c ("pipe: Add general notification queue support")
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c7cb60bff7aec24b834343ff433125f469886a3 upstream.

When building for Thumb2, the vectors make use of a local label. Sadly,
the Spectre BHB code also uses a local label with the same number which
results in the Thumb2 reference pointing at the wrong place. Fix this
by changing the number used for the Spectre BHB local label.

Fixes: b9baf5c8c5c3 ("ARM: Spectre-BHB workaround")
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>