Linux 5.15

Linux 5.15

[Linus Torvalds]

It's been calm, and I have no excuse to add an extra rc, so here we
are, with v5.15 pushed out, and the merge window starting tomorrow.

Which is going to be a bit inconvenient for me, since I also have some
conference travel coming up. But it's only a couple of days and I'll
have my laptop with me. Sometimes the release timing works out, and
sometimes it doesn't..

Anyway, the last week of 5.15 was mainly networking and gpu fixes,
with some random sprinkling of other things (a few btrfs reverts, some
kvm updates, minor other fixes here and there - a few architecture
fixes, couple of tracing, small driver fixes etc). Full shortlog
appended.

This release may have started out with some -Werror pain, but it
calmed down fairly quickly and on the whole 5.15 was fair small and
calm. Let's hope for more of the same - without Werror issues this
time - for the upcoming merge window.

                 Linus

---

Aaron Liu (1):
      drm/amdgpu: support B0&B1 external revision id for yellow carp

Adrian Hunter (1):
      perf build: Suppress 'rm dlfilter' build message

Aharon Landau (1):
      RDMA/mlx5: Initialize the ODP xarray when creating an ODP MR

Alexandre Ghiti (2):
      riscv: Do not re-populate shadow memory with kasan_populate_early_shadow
      riscv: Fix asan-stack clang build

Alexey Kardashevskiy (3):
      powerpc/pseries/iommu: Use correct vfree for it_map
      powerpc/pseries/iommu: Check if the default window in use before
removing it
      powerpc/pseries/iommu: Create huge DMA window if no MMIO32 is present

Amit Engel (1):
      nvmet-tcp: fix header digest verification

Amit Pundir (1):
      Revert "arm64: dts: qcom: sm8250: remove bus clock from the mdss
node for sm8250 target"

Andrew Lunn (4):
      phy: phy_ethtool_ksettings_get: Lock the phy for consistency
      phy: phy_ethtool_ksettings_set: Move after phy_start_aneg
      phy: phy_start_aneg: Add an unlocked version
      phy: phy_ethtool_ksettings_set: Lock the PHY while changing settings

Andy Shevchenko (1):
      mmc: sdhci-pci: Read card detect from ACPI for Intel Merrifield

Asmaa Mnebhi (1):
      gpio: mlxbf2.c: Add check for bgpio_init failure

Avri Altman (1):
      scsi: ufs: ufshpb: Remove HPB2.0 flows

Bastien Roucariès (1):
      ARM: dts: sun7i: A20-olinuxino-lime2: Fix ethernet phy-mode

Björn Töpel (1):
      riscv, bpf: Fix potential NULL dereference

Brian King (1):
      scsi: ibmvfc: Fix up duplicate response detection

Bryant Mairs (1):
      drm: panel-orientation-quirks: Add quirk for Aya Neo 2021

Chanho Park (1):
      scsi: ufs: ufs-exynos: Correct timeout value setting registers

Chen Lu (1):
      riscv: fix misalgned trap vector base address

Chen Wandun (1):
      mm/vmalloc: fix numa spreading for large hash tables

Christian König (1):
      drm/ttm: fix memleak in ttm_transfered_destroy

Christoph Hellwig (1):
      nvdimm/pmem: stop using q_usage_count as external pgmap refcount

Christoph Niedermaier (1):
      MAINTAINERS: Add maintainers for DHCOM i.MX6 and DHCOM/DHCOR STM32MP1

Clément Bœsch (1):
      arm64: dts: allwinner: h5: NanoPI Neo 2: Fix ethernet node

Cong Wang (3):
      net: Rename ->stream_memory_read to ->sock_is_readable
      skmsg: Extract and reuse sk_msg_is_readable()
      net: Implement ->sock_is_readable() for UDP and AF_UNIX

Cyril Strejc (1):
      net: multicast: calculate csum of looped-back and forwarded packets

Dan Carpenter (1):
      RDMA/rdmavt: Fix error code in rvt_create_qp()

Daniel Jordan (2):
      net/tls: Fix flipped sign in tls_err_abort() calls
      net/tls: Fix flipped sign in async_wait.err assignment

Daniel Vetter (2):
      drm/i915/selftests: Properly reset mock object propers for each test
      MAINTAINERS: dri-devel is for all of drivers/gpu

Dave Ertman (1):
      ice: Respond to a NETDEV_UNREGISTER event for LAG

David Sterba (4):
      Revert "btrfs: compression: drop kmap/kunmap from generic helpers"
      Revert "btrfs: compression: drop kmap/kunmap from zstd"
      Revert "btrfs: compression: drop kmap/kunmap from zlib"
      Revert "btrfs: compression: drop kmap/kunmap from lzo"

David Woodhouse (3):
      KVM: x86: switch pvclock_gtod_sync_lock to a raw spinlock
      KVM: x86/xen: Fix kvm_xen_has_interrupt() sleeping in kvm_vcpu_block()
      KVM: x86: Take srcu lock in post_kvm_run_save()

David Yang (1):
      tools/testing/selftests/vm/split_huge_page_test.c: fix
application of sizeof to pointer

Davide Caratti (1):
      mptcp: fix corrupt receiver key in MPC + data + checksum

Dongli Zhang (2):
      xen/netfront: stop tx queues during live migration
      vmxnet3: do not stop tx queues after netif_device_detach()

Eric Yang (1):
      drm/amd/display: increase Z9 latency to workaround underflow in Z9

Florian Westphal (1):
      fcnal-test: kill hanging ping/nettest binaries on cleanup

Frieder Schrempf (5):
      arm64: dts: imx8mm-kontron: Make sure SOC and DRAM supply
voltages are correct
      arm64: dts: imx8mm-kontron: Set lower limit of VDD_SNVS to 800 mV
      arm64: dts: imx8mm-kontron: Fix polarity of reg_rst_eth2
      arm64: dts: imx8mm-kontron: Fix CAN SPI clock frequency
      arm64: dts: imx8mm-kontron: Fix connection type for VSC8531 RGMII PHY

Gautham Ananthakrishna (1):
      ocfs2: fix race between searching chunks and release
journal_head from buffer_head

Geert Uytterhoeven (1):
      reset: pistachio: Re-enable driver selection

Guangbin Huang (5):
      net: hns3: fix pause config problem after autoneg disabled
      net: hns3: ignore reset event before initialization process is done
      net: hns3: expand buffer len for some debugfs command
      net: hns3: adjust string spaces of some parameters of tx bd info
in debugfs
      Revert "net: hns3: fix pause config problem after autoneg disabled"

Guenter Roeck (3):
      Revert "watchdog: iTCO_wdt: Account for rebooting on second timeout"
      watchdog: ixp4xx_wdt: Fix address space warning
      nios2: Make NIOS2_DTB_SOURCE_BOOL depend on !COMPILE_TEST

Haibo Chen (1):
      mmc: sdhci-esdhc-imx: clear the buffer_read_ready to reset
standard tuning circuit

Halil Pasic (2):
      KVM: s390: clear kicked_mask before sleeping again
      KVM: s390: preserve deliverable_mask in __airqs_kick_single_vcpu

Ido Schimmel (1):
      mlxsw: pci: Recycle received packet upon allocation failure

Imre Deak (1):
      drm/i915/dp: Skip the HW readout of DPCD on disabled encoders

Jaehoon Chung (1):
      mmc: dw_mmc: exynos: fix the finding clock sample value

Jake Wang (1):
      drm/amd/display: Moved dccg init to after bios golden init

Jamie Iles (1):
      watchdog: sbsa: only use 32-bit accessors

Janghyub Seo (1):
      r8169: Add device 10ec:8162 to driver r8169

Janusz Dziedzic (1):
      cfg80211: correct bridge/4addr mode check

Jie Wang (2):
      net: hns3: fix data endian problem of some functions of debugfs
      net: hns3: add more string spaces for dumping packets number of
queue info in debugfs

Jim Quinlan (1):
      reset: brcmstb-rescal: fix incorrect polarity of status bit

Jiri Olsa (1):
      perf callchain: Fix compilation on powerpc with gcc11+

Johan Hovold (2):
      net: lan78xx: fix division by zero in send path
      mmc: vub300: fix control-message timeouts

Johannes Berg (3):
      mac80211: mesh: fix HE operation element length check
      cfg80211: scan: fix RCU in cfg80211_add_nontrans_list()
      cfg80211: fix management registrations locking

Jonas Gorski (1):
      gpio: xgs-iproc: fix parsing of ngpios property

Joonas Lahtinen (1):
      drm/i915: Revert 'guc_id' from i915_request tracepoint

José Roberto de Souza (1):
      drm/i915: Remove memory frequency calculation

Kan Liang (1):
      perf script: Fix PERF_SAMPLE_WEIGHT_STRUCT support

Kees Cook (1):
      mm/secretmem: avoid letting secretmem_users drop to zero

Krzysztof Kozlowski (2):
      nfc: port100: fix using -ERRNO as command type mask
      watchdog: sbsa: drop unneeded MODULE_ALIAS

Linus Torvalds (1):
      Linux 5.15

Liu Jian (1):
      tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function

Lorenz Bauer (3):
      bpf: Define bpf_jit_alloc_exec_limit for riscv JIT
      bpf: Define bpf_jit_alloc_exec_limit for arm64 JIT
      bpf: Prevent increasing bpf_jit_limit above max

Mario (1):
      drm: panel-orientation-quirks: Add quirk for GPD Win3

Mark Zhang (1):
      RDMA/sa_query: Use strscpy_pad instead of memcpy to copy a string

Martin Blumenstingl (1):
      clk: composite: Also consider .determine_rate for rate + mux composites

Martin K. Petersen (1):
      scsi: mpt3sas: Fix reference tag handling for WRITE_INSERT

Maurizio Lombardi (1):
      nvmet-tcp: fix a memory leak when releasing a queue

Max VA (1):
      tipc: fix size validations for the MSG_CRYPTO type

Michael Chan (1):
      net: Prevent infinite while loop in skb_tx_hash()

Michael Strauss (1):
      drm/amd/display: Fallback to clocks which meet requested voltage on DCN31

Mike Marciniszyn (2):
      IB/qib: Protect from buffer overflow in struct qib_user_sdma_pkt fields
      IB/hfi1: Fix abba locking issue with sc_disable()

Mikko Perttunen (1):
      reset: tegra-bpmp: Handle errors in BPMP response

Ming Lei (1):
      block: drain queue after disk is removed from sysfs

Mustafa Ismail (2):
      RDMA/irdma: Set VLAN in UD work completion correctly
      RDMA/irdma: Do not hold qos mutex twice on QP resume

Naohiro Aota (1):
      block: schedule queue restart after BLK_STS_ZONE_RESOURCE

Nicholas Kazlauskas (3):
      drm/amd/display: Fix prefetch bandwidth calculation for DCN3.1
      drm/amd/display: Require immediate flip support for DCN3.1 planes
      drm/amd/display: Fix deadlock when falling back to v2 from v3

Nikola Cornij (2):
      drm/amd/display: Limit display scaling to up to true 4k for DCN 3.1
      drm/amd/display: Increase watermark latencies for DCN3.1

Paolo Bonzini (1):
      KVM: SEV-ES: fix another issue with string I/O VMGEXITs

Patrik Jakobsson (1):
      drm/amdgpu: Fix even more out of bound writes from debugfs

Patrisious Haddad (1):
      RDMA/mlx5: Set user priority for DCT

Pavel Skripkin (1):
      net: batman-adv: fix error handling

Paweł Anikiel (1):
      reset: socfpga: add empty driver allowing consumers to probe

Prabhakar Kushwaha (1):
      rdma/qedr: Fix crash due to redundant release of device's qp memory

Quanyang Wang (1):
      cgroup: Fix memory leak caused by missing cgroup_bpf_offline

Rakesh Babu (1):
      octeontx2-af: Display all enabled PF VF rsrc_alloc entries.

Rakesh Babu Saladi (1):
      octeontx2-af: Fix possible null pointer dereference.

Randy Dunlap (2):
      mmc: winbond: don't build on M68K
      ptp: Document the PTP_CLK_MAGIC ioctl number

Rongwei Wang (1):
      mm, thp: bail out early in collapse_file for writeback page

Russ Weight (1):
      spi: altera: Change to dynamic allocation of spi id

Sagi Grimberg (1):
      nvme-tcp: fix H2CData PDU send accounting (again)

SeongJae Park (1):
      mm/damon/core-test: fix wrong expectations for 'damon_split_regions_of()'

Shakeel Butt (1):
      memcg: page_alloc: skip bulk allocator for __GFP_ACCOUNT

Shawn Guo (1):
      mmc: sdhci: Map more voltage level to SDHCI_POWER_330

Shin'ichiro Kawasaki (1):
      block: Fix partition check for host-aware zoned block devices

Shiraz Saleem (1):
      RDMA/irdma: Process extended CQ entries correctly

Song Liu (1):
      perf script: Check session->header.env.arch before using it

Steven Rostedt (VMware) (4):
      ftrace/nds32: Update the proto for ftrace_trace_function to
match ftrace_stub
      tracing: Do not warn when connecting eprobe to non existing event
      ftrace: Fix kernel-doc formatting issues
      tracing: Fix misspelling of "missing"

Subbaraya Sundeep (1):
      octeontx2-af: Check whether ipolicers exists

Suren Baghdasaryan (1):
      mm/oom_kill.c: prevent a race between process_mrelease and exit_mmap

Tejun Heo (1):
      bpf: Move BPF_MAP_TYPE for INODE_STORAGE and TASK_STORAGE
outside of CONFIG_NET

Thelford Williams (1):
      drm/amdgpu: fix out of bounds write

Thomas Perrot (1):
      spi: spl022: fix Microwire full duplex mode

Tianjia Zhang (1):
      crypto: x86/sm4 - Fix invalid section entry size

Toke Høiland-Jørgensen (1):
      bpf: Fix potential race in tail call compatibility check

Tony Lu (1):
      net/smc: Fix smc_link->llc_testlink_time overflow

Trevor Woerner (1):
      net: nxp: lpc_eth.c: avoid hang when bringing interface down

Vadym Kochan (1):
      MAINTAINERS: please remove myself from the Prestera driver

Varun Prakash (3):
      nvme-tcp: fix possible req->offset corruption
      nvme-tcp: fix data digest pointer calculation
      nvmet-tcp: fix data digest pointer calculation

Vasily Averin (1):
      skb_expand_head() adjust skb->truesize incorrectly

Ville Syrjälä (2):
      drm/i915: Convert unconditional clflush to drm_clflush_virt_range()
      drm/i915: Catch yet another unconditioal clflush

Vincent Whitchurch (1):
      virtio-ring: fix DMA metadata flags

Walter Stoll (1):
      watchdog: Fix OMAP watchdog early handling

Wang Hai (1):
      usbnet: fix error return code in usbnet_probe()

Wen Gu (1):
      net/smc: Correct spelling mistake to TCPF_SYN_RECV

Wenbin Mei (2):
      mmc: cqhci: clear HALT state after CQE enable
      mmc: mediatek: Move cqhci init behind ungate clock

Wolfram Sang (1):
      mmc: tmio: reenable card irqs after the reset callback

Xie Yongji (2):
      vduse: Disallow injecting interrupt before DRIVER_OK is set
      vduse: Fix race condition between resetting and irq injecting

Xin Long (8):
      sctp: use init_tag from inithdr for ABORT chunk
      sctp: fix the processing for INIT chunk
      sctp: fix the processing for INIT_ACK chunk
      sctp: fix the processing for COOKIE_ECHO chunk
      sctp: add vtag check in sctp_sf_violation
      sctp: add vtag check in sctp_sf_do_8_5_1_E_sa
      sctp: add vtag check in sctp_sf_ootb
      net-sysfs: initialize uid and gid before calling net_ns_get_ownership

Xu Kuohai (1):
      bpf: Fix error usage of map_fd and fdget() in generic_map_update_batch()

Yang Shi (3):
      mm: hwpoison: remove the unnecessary THP check
      mm: filemap: check if THP has hwpoisoned subpage for PMD page fault
      mm: khugepaged: skip huge page collapse for special files

Yang Yingliang (1):
      regmap: Fix possible double-free in regcache_rbtree_exit()

Yongxin Liu (1):
      ice: check whether PTP is initialized in ice_ptp_release()

Yu Xiao (1):
      nfp: bpf: relax prog rejection for mtu check through max_pkt_offset

Yucong Sun (1):
      selftests/bpf: Use recv_timeout() instead of retries

Yufeng Mo (1):
      net: hns3: change hclge/hclgevf workqueue to WQ_UNBOUND mode

Yuiko Oshino (3):
      net: ethernet: microchip: lan743x: Fix driver crash when
lan743x_pm_resume fails
      net: ethernet: microchip: lan743x: Fix dma allocation failure by
using dma_set_mask_and_coherent
      net: ethernet: microchip: lan743x: Fix skb allocation failure

Re: Linux 5.15

[Guenter Roeck]

On Sun, Oct 31, 2021 at 02:09:07PM -0700, Linus Torvalds wrote:
> It's been calm, and I have no excuse to add an extra rc, so here we
> are, with v5.15 pushed out, and the merge window starting tomorrow.
> 
> Which is going to be a bit inconvenient for me, since I also have some
> conference travel coming up. But it's only a couple of days and I'll
> have my laptop with me. Sometimes the release timing works out, and
> sometimes it doesn't..
> 
> Anyway, the last week of 5.15 was mainly networking and gpu fixes,
> with some random sprinkling of other things (a few btrfs reverts, some
> kvm updates, minor other fixes here and there - a few architecture
> fixes, couple of tracing, small driver fixes etc). Full shortlog
> appended.
> 
> This release may have started out with some -Werror pain, but it
> calmed down fairly quickly and on the whole 5.15 was fair small and
> calm. Let's hope for more of the same - without Werror issues this
> time - for the upcoming merge window.
> 

Here are my test results:

Build results:
	total: 154 pass: 153 fail: 1
Failed builds:
	m68k:allmodconfig
Qemu test results:
	total: 480 pass: 480 fail: 0

The build error is:

Building m68k:allmodconfig ... failed
--------------
Error log:
In file included from include/linux/string.h:20,
                 from include/linux/bitmap.h:10,
                 from include/linux/cpumask.h:12,
                 from include/linux/smp.h:13,
                 from include/linux/lockdep.h:14,
                 from include/linux/spinlock.h:63,
                 from include/linux/mmzone.h:8,
                 from include/linux/gfp.h:6,
                 from include/linux/slab.h:15,
                 from drivers/nvme/target/discovery.c:7:
In function 'memcpy_and_pad',
    inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2:
arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7

Another instance of the same problem:

In function 'memcpy_and_pad',
    inlined from 'nvmet_execute_identify_ctrl' at drivers/nvme/target/admin-cmd.c:372:2:
arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7

This is seen with gcc 11.1 and 11.2. gcc 10.3 builds fine.
The code in question is

        memcpy_and_pad(id->fr, sizeof(id->fr),
                       UTS_RELEASE, strlen(UTS_RELEASE), ' ');

and UTS_RELEASE is "5.15.0". I have no idea what might be wrong with the code.
Does anyone have an idea ? Do I need to revert to gcc 10.3 for m68k ?

Thanks,
Guenter

Re: Linux 5.15

[Geert Uytterhoeven]

Hi Günter.

On Mon, Nov 1, 2021 at 1:28 AM Guenter Roeck <linux@roeck-us.net> wrote:
> On Sun, Oct 31, 2021 at 02:09:07PM -0700, Linus Torvalds wrote:
> Building m68k:allmodconfig ... failed
> --------------
> Error log:
> In file included from include/linux/string.h:20,
>                  from include/linux/bitmap.h:10,
>                  from include/linux/cpumask.h:12,
>                  from include/linux/smp.h:13,
>                  from include/linux/lockdep.h:14,
>                  from include/linux/spinlock.h:63,
>                  from include/linux/mmzone.h:8,
>                  from include/linux/gfp.h:6,
>                  from include/linux/slab.h:15,
>                  from drivers/nvme/target/discovery.c:7:
> In function 'memcpy_and_pad',
>     inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2:
> arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7
>
> Another instance of the same problem:
>
> In function 'memcpy_and_pad',
>     inlined from 'nvmet_execute_identify_ctrl' at drivers/nvme/target/admin-cmd.c:372:2:
> arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7
>
> This is seen with gcc 11.1 and 11.2. gcc 10.3 builds fine.
> The code in question is
>
>         memcpy_and_pad(id->fr, sizeof(id->fr),
>                        UTS_RELEASE, strlen(UTS_RELEASE), ' ');
>
> and UTS_RELEASE is "5.15.0". I have no idea what might be wrong with the code.

Me neither.  That warning (now error) has been seen with all point
releases (i.e. strlen(UTS_RELEASE) < 8) since v5.0.

> Does anyone have an idea ?

We had a discussion in
https://lore.kernel.org/all/CAMuHMdX365qmWiii=gQLADpW49EMkdDrVJDPWNBpAZuZM0WQFQ@mail.gmail.com
but without any definitive conclusion.

> Do I need to revert to gcc 10.3 for m68k ?

I'm not sure that might help, as the issue has been seen with
e.g. 8.1.0 and 8.2.0, too, with a slightly different message:
warning: ‘__builtin_memcpy’ forming offset 8 is out of the bounds [0,
7] [-Warray-bounds]

Any suggestions? Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Linux 5.15

[Guenter Roeck]

On 11/1/21 1:13 AM, Geert Uytterhoeven wrote:
> Hi Günter.
> 
> On Mon, Nov 1, 2021 at 1:28 AM Guenter Roeck <linux@roeck-us.net> wrote:
>> On Sun, Oct 31, 2021 at 02:09:07PM -0700, Linus Torvalds wrote:
>> Building m68k:allmodconfig ... failed
>> --------------
>> Error log:
>> In file included from include/linux/string.h:20,
>>                   from include/linux/bitmap.h:10,
>>                   from include/linux/cpumask.h:12,
>>                   from include/linux/smp.h:13,
>>                   from include/linux/lockdep.h:14,
>>                   from include/linux/spinlock.h:63,
>>                   from include/linux/mmzone.h:8,
>>                   from include/linux/gfp.h:6,
>>                   from include/linux/slab.h:15,
>>                   from drivers/nvme/target/discovery.c:7:
>> In function 'memcpy_and_pad',
>>      inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2:
>> arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7
>>
>> Another instance of the same problem:
>>
>> In function 'memcpy_and_pad',
>>      inlined from 'nvmet_execute_identify_ctrl' at drivers/nvme/target/admin-cmd.c:372:2:
>> arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7
>>
>> This is seen with gcc 11.1 and 11.2. gcc 10.3 builds fine.
>> The code in question is
>>
>>          memcpy_and_pad(id->fr, sizeof(id->fr),
>>                         UTS_RELEASE, strlen(UTS_RELEASE), ' ');
>>
>> and UTS_RELEASE is "5.15.0". I have no idea what might be wrong with the code.
> 
> Me neither.  That warning (now error) has been seen with all point
> releases (i.e. strlen(UTS_RELEASE) < 8) since v5.0.
> 

Ah yes, I can see that now. I guess I didn't notice earlier because it was
only reported as warning.

>> Does anyone have an idea ?
> 
> We had a discussion in
> https://lore.kernel.org/all/CAMuHMdX365qmWiii=gQLADpW49EMkdDrVJDPWNBpAZuZM0WQFQ@mail.gmail.com
> but without any definitive conclusion.
> 
>> Do I need to revert to gcc 10.3 for m68k ?
> 
> I'm not sure that might help, as the issue has been seen with
> e.g. 8.1.0 and 8.2.0, too, with a slightly different message:
> warning: ‘__builtin_memcpy’ forming offset 8 is out of the bounds [0,
> 7] [-Warray-bounds]
> 
> Any suggestions? Thanks!
> 

Replacing "strlen(UTS_RELEASE)" with "sizeof(UTS_RELEASE) - 1" seems to do
the trick, at least with gcc 11.2 and v5.15. I just wonder if that would be
acceptable. Any idea ?

Thanks,
Guenter

Re: Linux 5.15

[Linus Torvalds]

On Mon, Nov 1, 2021 at 6:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Replacing "strlen(UTS_RELEASE)" with "sizeof(UTS_RELEASE) - 1" seems to do
> the trick, at least with gcc 11.2 and v5.15. I just wonder if that would be
> acceptable. Any idea ?

Looks sane to me.

I don't understand why gcc complains about that thing in the first
place, much less why it only happens on m68k, but whatever...

The other - and perhaps better - option would be to just uninline
memcpy_and_pad() entirely, move it to lib/string.c, and only have the
declaration in <linux/string.h>.

Because the only reason to have it as an inline function is when the
compiler can statically optimize a call site: but it's really not a
performance-critical function to begin with, and clearly the compiler
instead just *breaks* rather than optimize that call-site.

               Linus

Re: Linux 5.15

[Guenter Roeck]

On Mon, Nov 01, 2021 at 06:44:39PM -0700, Linus Torvalds wrote:
> On Mon, Nov 1, 2021 at 6:18 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Replacing "strlen(UTS_RELEASE)" with "sizeof(UTS_RELEASE) - 1" seems to do
> > the trick, at least with gcc 11.2 and v5.15. I just wonder if that would be
> > acceptable. Any idea ?
> 
> Looks sane to me.
> 
> I don't understand why gcc complains about that thing in the first
> place, much less why it only happens on m68k, but whatever...
> 
> The other - and perhaps better - option would be to just uninline
> memcpy_and_pad() entirely, move it to lib/string.c, and only have the
> declaration in <linux/string.h>.
> 
> Because the only reason to have it as an inline function is when the
> compiler can statically optimize a call site: but it's really not a
> performance-critical function to begin with, and clearly the compiler
> instead just *breaks* rather than optimize that call-site.
> 
Excellent suggestion. I'll submit a patch to do just that.

Thanks,
Guenter

Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Thorsten Leemhuis]

On 31.10.21 22:09, Linus Torvalds wrote:
> It's been calm, and I have no excuse to add an extra rc, so here we
> are, with v5.15 pushed out, and the merge window starting tomorrow.

TLDR: Please tell me directly (by CC or forward) or via regzbot (see
below) about any regression reports you stumble upon, as I'm giving
regression tracking another shot. This time I'm doing it with the help
of a bot, which really could need a lot to chew on for a proper test-run.

Hi everyone! Years ago I did regression tracking for the Linux kernel
for a while. Back then tracking and writing weekly reports was a manual
and quite exhausting effort. Nevertheless, I'm giving regression
tracking another shot. But this time I'll leave the hard work to a bot I
wrote just for this purpose, which is specifically tailored to the needs
of Linux kernel development. I tested this 'regzbot' a little in the
past few weeks, but I need more regression reports now to shake out bugs
and see where things might need big adjustments or fine-tuning.

Hence, if you see any regression reports, please tell be about them, for
example by simply forwarding the mail to regressions@leemhuis.info or
CCing that address on a reply. I'll handle everything else then and tell
regzbot about it. But if you feel adventurous, you can also skip me as
the man-in-the-middle and tell the bot directly. To do that, just send a
reply to the report to the regressions mailing list
(regressions@lists.linux.dev) either directly or by CCing it on a reply
you would have written anyway; when doing so, place something like
'#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
the text, as outlined in regzbot's 'getting started guide' or its
reference documentation:
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md

That's it, regzbot then on its next run will add the report to the list
of tracked regression. I'll keep an eye on things and try to fix any
problems I notice, as there likely will be a few. But then doesn't need
to bother you.

There is one thing that would really help: if one or two subsystem
maintainers could give regzbot a shot for all the regression reports
they get, even for easy fixes, as the bot really needs something to chew
on. Any volunteers?

As years ago I'll send weekly regression reports, but this time they
will get generated directly from regzbot. But thx to the bot there is
now also a web-view which provides an always up2date view into the data
gathered by regzbot:
https://linux-regtracking.leemhuis.info/regzbot/mainline/

Ciao, Thorsten

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Greg KH]

On Mon, Nov 01, 2021 at 12:46:33PM +0100, Idzibear wrote:
> https://www.reddit.com/r/linux/comments/qjyxso/the_515_kernel_has_been_released/hitiykt/
> 
> I just noticed something strange. I'm experimenting with some repurposed
> Desktop-PC to make it maybe into a homelab server.
> 
> I ran Kernel 5.14.10, and I had an idle usage of 19-22 watts. Updated to
> 5.15 and it went to 27-29 watts. Went back to 5.14.10 and it went down to
> 19-22 watts again. WTF?

Odd, any chance you can use 'git bisect' and track down the offending
commit?

thanks,

greg k-h

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Thorsten Leemhuis]

On 01.11.21 12:46, Idzibear wrote:
> https://www.reddit.com/r/linux/comments/qjyxso/the_515_kernel_has_been_released/hitiykt/
> 
> I just noticed something strange. I'm experimenting with some repurposed
> Desktop-PC to make it maybe into a homelab server.
> 
> I ran Kernel 5.14.10, and I had an idle usage of 19-22 watts. Updated to
> 5.15 and it went to 27-29 watts. Went back to 5.14.10 and it went down
> to 19-22 watts again. WTF?

thx for the report, yeah, sound like a regression. With that much of a
difference I'd suspect it's something that can consume a lot of power if
not sleeping properly, for example the CPU or the GPU. But that's just a
shot in the dark and it's hard to help here with debugging from a
distance (especially without a list of hardware components). With a bit
of luck tools like powertop might be able to debug this (check if the
CPU is sleeping well). But a 'git bisect', like already suggested
Gregkh, would be really the best to find the change that's causing this.

Ciao, Thorsten

#regzbot ^introduced: v5.14..v5.15
#regzbot title: idle power increased from ~20 to ~28 watts

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Greg KH]

On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
> example by simply forwarding the mail to regressions@leemhuis.info or
> CCing that address on a reply. I'll handle everything else then and tell
> regzbot about it. But if you feel adventurous, you can also skip me as
> the man-in-the-middle and tell the bot directly. To do that, just send a
> reply to the report to the regressions mailing list
> (regressions@lists.linux.dev) either directly or by CCing it on a reply
> you would have written anyway; when doing so, place something like
> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
> the text, as outlined in regzbot's 'getting started guide' or its
> reference documentation:
> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
> 
> That's it, regzbot then on its next run will add the report to the list
> of tracked regression. I'll keep an eye on things and try to fix any
> problems I notice, as there likely will be a few. But then doesn't need
> to bother you.
> 
> There is one thing that would really help: if one or two subsystem
> maintainers could give regzbot a shot for all the regression reports
> they get, even for easy fixes, as the bot really needs something to chew
> on. Any volunteers?

I'll try it for the USB subsystem this merge cycle.  Do you want a bug
report email redirected to that address or will a simple forward work
well enough?

thanks,

greg k-h

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Thorsten Leemhuis]

On 01.11.21 13:33, Greg KH wrote:
> On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
>> example by simply forwarding the mail to regressions@leemhuis.info or
>> CCing that address on a reply. I'll handle everything else then and tell
>> regzbot about it. But if you feel adventurous, you can also skip me as
>> the man-in-the-middle and tell the bot directly. To do that, just send a
>> reply to the report to the regressions mailing list
>> (regressions@lists.linux.dev) either directly or by CCing it on a reply
>> you would have written anyway; when doing so, place something like
>> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
>> the text, as outlined in regzbot's 'getting started guide' or its
>> reference documentation:
>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
>>
>> That's it, regzbot then on its next run will add the report to the list
>> of tracked regression. I'll keep an eye on things and try to fix any
>> problems I notice, as there likely will be a few. But then doesn't need
>> to bother you.
>>
>> There is one thing that would really help: if one or two subsystem
>> maintainers could give regzbot a shot for all the regression reports
>> they get, even for easy fixes, as the bot really needs something to chew
>> on. Any volunteers?
> 
> I'll try it for the USB subsystem this merge cycle. 

That will be a great help, many thx.

> Do you want a bug
> report email redirected to that address or will a simple forward work
> well enough?

Redirecting will make it a little easier for me, but a simple forward is
fine, too.

thx!

Ciao, Thorsten

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Greg KH]

On Mon, Nov 01, 2021 at 01:44:01PM +0100, Thorsten Leemhuis wrote:
> On 01.11.21 13:33, Greg KH wrote:
> > On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
> >> example by simply forwarding the mail to regressions@leemhuis.info or
> >> CCing that address on a reply. I'll handle everything else then and tell
> >> regzbot about it. But if you feel adventurous, you can also skip me as
> >> the man-in-the-middle and tell the bot directly. To do that, just send a
> >> reply to the report to the regressions mailing list
> >> (regressions@lists.linux.dev) either directly or by CCing it on a reply
> >> you would have written anyway; when doing so, place something like
> >> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
> >> the text, as outlined in regzbot's 'getting started guide' or its
> >> reference documentation:
> >> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
> >> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
> >>
> >> That's it, regzbot then on its next run will add the report to the list
> >> of tracked regression. I'll keep an eye on things and try to fix any
> >> problems I notice, as there likely will be a few. But then doesn't need
> >> to bother you.
> >>
> >> There is one thing that would really help: if one or two subsystem
> >> maintainers could give regzbot a shot for all the regression reports
> >> they get, even for easy fixes, as the bot really needs something to chew
> >> on. Any volunteers?
> > 
> > I'll try it for the USB subsystem this merge cycle. 
> 
> That will be a great help, many thx.
> 
> > Do you want a bug
> > report email redirected to that address or will a simple forward work
> > well enough?
> 
> Redirecting will make it a little easier for me, but a simple forward is
> fine, too.

Ok, I did that now for a USB bug report, hopefully that worked.  If not,
I can forward it on.

thanks,

greg k-h

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Thorsten Leemhuis]

On 01.11.21 14:03, Greg KH wrote:
> On Mon, Nov 01, 2021 at 01:44:01PM +0100, Thorsten Leemhuis wrote:
>> On 01.11.21 13:33, Greg KH wrote:
>>> On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
>>>> example by simply forwarding the mail to regressions@leemhuis.info or
>>>> CCing that address on a reply. I'll handle everything else then and tell
>>>> regzbot about it. But if you feel adventurous, you can also skip me as
>>>> the man-in-the-middle and tell the bot directly. To do that, just send a
>>>> reply to the report to the regressions mailing list
>>>> (regressions@lists.linux.dev) either directly or by CCing it on a reply
>>>> you would have written anyway; when doing so, place something like
>>>> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
>>>> the text, as outlined in regzbot's 'getting started guide' or its
>>>> reference documentation:
>>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
>>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
>>>>
>>>> That's it, regzbot then on its next run will add the report to the list
>>>> of tracked regression. I'll keep an eye on things and try to fix any
>>>> problems I notice, as there likely will be a few. But then doesn't need
>>>> to bother you.
>>>>
>>>> There is one thing that would really help: if one or two subsystem
>>>> maintainers could give regzbot a shot for all the regression reports
>>>> they get, even for easy fixes, as the bot really needs something to chew
>>>> on. Any volunteers?
>>>
>>> I'll try it for the USB subsystem this merge cycle. 
>>
>> That will be a great help, many thx.
>>
>>> Do you want a bug
>>> report email redirected to that address or will a simple forward work
>>> well enough?
>>
>> Redirecting will make it a little easier for me, but a simple forward is
>> fine, too.
> 
> Ok, I did that now for a USB bug report, hopefully that worked.  If not,
> I can forward it on.

Got it, but I could need some advice on it if you have a minute.

Does that report really look like a regression from your point of view?
The part "The code has been this way in the kernel for a very long time,
which suggests that it has been working, [...]" sounds like it is, but
OTOH it's quite vague.

I'm asking, because with my regression tracking work and regzbot I focus
on regressions and ignore things that were always broken, as I (at least
for now) don't want it to become yet another bug tracker (and I guess I
would quickly drown in bugs as well).

But if you think this case looks like a regression, I'll add it. Guess I
just need to be creative then how to tell regzbot when it got
introduced. Guess I'll settle on v2.6.13..v5.15", that should indicate
there is something strange here. It's a use-case I hadn't expected. But
well, that's why I wanted to something for testing. :-D

Ciao, Thorsten

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Greg KH]

On Mon, Nov 01, 2021 at 02:34:21PM +0100, Thorsten Leemhuis wrote:
> On 01.11.21 14:03, Greg KH wrote:
> > On Mon, Nov 01, 2021 at 01:44:01PM +0100, Thorsten Leemhuis wrote:
> >> On 01.11.21 13:33, Greg KH wrote:
> >>> On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
> >>>> example by simply forwarding the mail to regressions@leemhuis.info or
> >>>> CCing that address on a reply. I'll handle everything else then and tell
> >>>> regzbot about it. But if you feel adventurous, you can also skip me as
> >>>> the man-in-the-middle and tell the bot directly. To do that, just send a
> >>>> reply to the report to the regressions mailing list
> >>>> (regressions@lists.linux.dev) either directly or by CCing it on a reply
> >>>> you would have written anyway; when doing so, place something like
> >>>> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
> >>>> the text, as outlined in regzbot's 'getting started guide' or its
> >>>> reference documentation:
> >>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
> >>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
> >>>>
> >>>> That's it, regzbot then on its next run will add the report to the list
> >>>> of tracked regression. I'll keep an eye on things and try to fix any
> >>>> problems I notice, as there likely will be a few. But then doesn't need
> >>>> to bother you.
> >>>>
> >>>> There is one thing that would really help: if one or two subsystem
> >>>> maintainers could give regzbot a shot for all the regression reports
> >>>> they get, even for easy fixes, as the bot really needs something to chew
> >>>> on. Any volunteers?
> >>>
> >>> I'll try it for the USB subsystem this merge cycle. 
> >>
> >> That will be a great help, many thx.
> >>
> >>> Do you want a bug
> >>> report email redirected to that address or will a simple forward work
> >>> well enough?
> >>
> >> Redirecting will make it a little easier for me, but a simple forward is
> >> fine, too.
> > 
> > Ok, I did that now for a USB bug report, hopefully that worked.  If not,
> > I can forward it on.
> 
> Got it, but I could need some advice on it if you have a minute.
> 
> Does that report really look like a regression from your point of view?
> The part "The code has been this way in the kernel for a very long time,
> which suggests that it has been working, [...]" sounds like it is, but
> OTOH it's quite vague.

Later in the thread it was determined that this is a regression that
showed up in the 3.4 kernel release and the commit id was referenced.

> I'm asking, because with my regression tracking work and regzbot I focus
> on regressions and ignore things that were always broken, as I (at least
> for now) don't want it to become yet another bug tracker (and I guess I
> would quickly drown in bugs as well).

I agree, this shouldn't be a bug tracker, sorry, I shouldn't have
started this with a report of a really old issue, but it's all I found
at short notice :)

I've found another report of a regression that is newer for USB and
bounced it to you as well.  Hopefully that is a bit easier to track.

thanks,

greg k-h

Re: Thorsten is tracking regression again and could need a little help (was: Re: Linux 5.15)

[Thorsten Leemhuis]

On 01.11.21 16:27, Greg KH wrote:
> On Mon, Nov 01, 2021 at 02:34:21PM +0100, Thorsten Leemhuis wrote:
>> On 01.11.21 14:03, Greg KH wrote:
>>> On Mon, Nov 01, 2021 at 01:44:01PM +0100, Thorsten Leemhuis wrote:
>>>> On 01.11.21 13:33, Greg KH wrote:
>>>>> On Mon, Nov 01, 2021 at 05:49:40AM +0100, Thorsten Leemhuis wrote:
>>>>>> example by simply forwarding the mail to regressions@leemhuis.info or
>>>>>> CCing that address on a reply. I'll handle everything else then and tell
>>>>>> regzbot about it. But if you feel adventurous, you can also skip me as
>>>>>> the man-in-the-middle and tell the bot directly. To do that, just send a
>>>>>> reply to the report to the regressions mailing list
>>>>>> (regressions@lists.linux.dev) either directly or by CCing it on a reply
>>>>>> you would have written anyway; when doing so, place something like
>>>>>> '#regzbot ^introduced v5.15..' (separated by blank lines) somewhere in
>>>>>> the text, as outlined in regzbot's 'getting started guide' or its
>>>>>> reference documentation:
>>>>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md
>>>>>> https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md
>>>>>>
>>>>>> That's it, regzbot then on its next run will add the report to the list
>>>>>> of tracked regression. I'll keep an eye on things and try to fix any
>>>>>> problems I notice, as there likely will be a few. But then doesn't need
>>>>>> to bother you.
>>>>>>
>>>>>> There is one thing that would really help: if one or two subsystem
>>>>>> maintainers could give regzbot a shot for all the regression reports
>>>>>> they get, even for easy fixes, as the bot really needs something to chew
>>>>>> on. Any volunteers?
>>>>>
>>>>> I'll try it for the USB subsystem this merge cycle. 
>>>>
>>>> That will be a great help, many thx.
>>>>
>>>>> Do you want a bug
>>>>> report email redirected to that address or will a simple forward work
>>>>> well enough?
>>>>
>>>> Redirecting will make it a little easier for me, but a simple forward is
>>>> fine, too.
>>>
>>> Ok, I did that now for a USB bug report, hopefully that worked.  If not,
>>> I can forward it on.
>>
>> Got it, but I could need some advice on it if you have a minute.
>>
>> Does that report really look like a regression from your point of view?
>> The part "The code has been this way in the kernel for a very long time,
>> which suggests that it has been working, [...]" sounds like it is, but
>> OTOH it's quite vague.
> 
> Later in the thread it was determined that this is a regression that
> showed up in the 3.4 kernel release and the commit id was referenced.

Hah, stupid me, sorry, should have looked closer myself, thx for the
pointer.

>> I'm asking, because with my regression tracking work and regzbot I focus
>> on regressions and ignore things that were always broken, as I (at least
>> for now) don't want it to become yet another bug tracker (and I guess I
>> would quickly drown in bugs as well).
>
> I agree, this shouldn't be a bug tracker, sorry, I shouldn't have
> started this with a report of a really old issue, but it's all I found
> at short notice :)

No worries, I'm glad I get something to test regzbot better :-D

> I've found another report of a regression that is newer for USB and
> bounced it to you as well.  Hopefully that is a bit easier to track.

Many thx, much appreciated!

Ciao, Thorsten

Re: Linux 5.15

[Andy Shevchenko]

On Sun, Oct 31, 2021 at 11:09 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> It's been calm, and I have no excuse to add an extra rc, so here we
> are, with v5.15 pushed out, and the merge window starting tomorrow.
>
> Which is going to be a bit inconvenient for me, since I also have some
> conference travel coming up. But it's only a couple of days and I'll
> have my laptop with me. Sometimes the release timing works out, and
> sometimes it doesn't..
>
> Anyway, the last week of 5.15 was mainly networking and gpu fixes,
> with some random sprinkling of other things (a few btrfs reverts, some
> kvm updates, minor other fixes here and there - a few architecture
> fixes, couple of tracing, small driver fixes etc). Full shortlog
> appended.
>
> This release may have started out with some -Werror pain, but it
> calmed down fairly quickly and on the whole 5.15 was fair small and
> calm. Let's hope for more of the same - without Werror issues this
> time - for the upcoming merge window.

Do we really now have any use of COMPILE_TEST=y WERROR=y with `make W=1`?
To me it seems every CI just disabled it because it's impossible to
build a kernel anymore.

What is the roadmap of fixing this (to some extent)?

I remember that Lee spent a lot of time cleaning up W=1 cases. Maybe
he knows the state of affairs of this with -Werror enabled...


-- 
With Best Regards,
Andy Shevchenko

Re: Linux 5.15

[Lee Jones]

On Mon, 01 Nov 2021, Andy Shevchenko wrote:

> On Sun, Oct 31, 2021 at 11:09 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > It's been calm, and I have no excuse to add an extra rc, so here we
> > are, with v5.15 pushed out, and the merge window starting tomorrow.
> >
> > Which is going to be a bit inconvenient for me, since I also have some
> > conference travel coming up. But it's only a couple of days and I'll
> > have my laptop with me. Sometimes the release timing works out, and
> > sometimes it doesn't..
> >
> > Anyway, the last week of 5.15 was mainly networking and gpu fixes,
> > with some random sprinkling of other things (a few btrfs reverts, some
> > kvm updates, minor other fixes here and there - a few architecture
> > fixes, couple of tracing, small driver fixes etc). Full shortlog
> > appended.
> >
> > This release may have started out with some -Werror pain, but it
> > calmed down fairly quickly and on the whole 5.15 was fair small and
> > calm. Let's hope for more of the same - without Werror issues this
> > time - for the upcoming merge window.
> 
> Do we really now have any use of COMPILE_TEST=y WERROR=y with `make W=1`?
> To me it seems every CI just disabled it because it's impossible to
> build a kernel anymore.
> 
> What is the roadmap of fixing this (to some extent)?
> 
> I remember that Lee spent a lot of time cleaning up W=1 cases. Maybe
> he knows the state of affairs of this with -Werror enabled...

Probably never.  I managed to get the warnings down from ~18k to ~2k
IIRC.  However subsystems like GPU keep adding 10's of them every
release, so the job became perpetual.

I do plan on doing another rotation once I get a bit more free time.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: Linux 5.15

[Sudip Mukherjee]

On Sun, Oct 31, 2021 at 9:11 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> It's been calm, and I have no excuse to add an extra rc, so here we
> are, with v5.15 pushed out, and the merge window starting tomorrow.

My nightly testing tested "5.15.0-8bb7eca972ad" and looked ok with:
x86_64 qemu - https://openqa.qa.codethink.co.uk/tests/320
ppc64 qemu - https://openqa.qa.codethink.co.uk/tests/321
rpi4 - https://openqa.qa.codethink.co.uk/tests/322


-- 
Regards
Sudip