This is the start of the stable review cycle for the 5.10.213 release.
There are 73 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
        https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
or in the git tree and branch at:
        git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.

Thanks,
Sasha

-------------
Pseudo-Shortlog of commits:

Andrea Parri (Microsoft) (1):
  Drivers: hv: vmbus: Drop error message when 'No request id available'

Andres Beltran (2):
  Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus
    hardening
  hv_netvsc: Use vmbus_requestor to generate transaction IDs for VMBus
    hardening

Andy Shevchenko (4):
  serial: max310x: Use devm_clk_get_optional() to get the input clock
  serial: max310x: Try to get crystal clock rate from property
  serial: max310x: Make use of device properties
  serial: max310x: Unprepare and disable clock in error path

Ansuel Smith (1):
  regmap: allow to define reg_update_bits for no bus configuration

Baokun Li (1):
  ext4: make ext4_es_insert_extent() return void

Christophe Kerello (1):
  mmc: mmci: stm32: fix DMA API overlapping mappings warning

Cosmin Tanislav (4):
  serial: max310x: use regmap methods for SPI batch operations
  serial: max310x: use a separate regmap for each port
  serial: max310x: make accessing revision id interface-agnostic
  serial: max310x: implement I2C support

Dexuan Cui (1):
  hv_netvsc: Make netvsc/VF binding check both MAC and serial number

Edward Adam Davis (1):
  net/rds: fix WARNING in rds_conn_connect_if_down

Eric Dumazet (2):
  geneve: make sure to pull inner header in geneve_rx()
  net/ipv6: avoid possible UAF in ip6_route_mpath_notify()

Florian Westphal (1):
  netfilter: nft_ct: fix l3num expectations with inet pseudo family

Hugo Villeneuve (2):
  serial: max310x: fail probe if clock crystal is unstable
  serial: max310x: prevent infinite while() loop in port startup

Ingo Molnar (1):
  exit: Fix typo in comment: s/sub-theads/sub-threads

Jan Kundrát (1):
  serial: max310x: fix IO data corruption in batched operations

Jason Xing (12):
  netrom: Fix a data-race around sysctl_netrom_default_path_quality
  netrom: Fix a data-race around
    sysctl_netrom_obsolescence_count_initialiser
  netrom: Fix data-races around sysctl_netrom_network_ttl_initialiser
  netrom: Fix a data-race around sysctl_netrom_transport_timeout
  netrom: Fix a data-race around sysctl_netrom_transport_maximum_tries
  netrom: Fix a data-race around
    sysctl_netrom_transport_acknowledge_delay
  netrom: Fix a data-race around sysctl_netrom_transport_busy_delay
  netrom: Fix a data-race around
    sysctl_netrom_transport_requested_window_size
  netrom: Fix a data-race around
    sysctl_netrom_transport_no_activity_timeout
  netrom: Fix a data-race around sysctl_netrom_routing_control
  netrom: Fix a data-race around sysctl_netrom_link_fails_count
  netrom: Fix data-races around sysctl_net_busy_read

Johannes Berg (1):
  um: allow not setting extra rpaths in the linux binary

John Efstathiades (4):
  lan78xx: Fix white space and style issues
  lan78xx: Add missing return code checks
  lan78xx: Fix partial packet errors on suspend/resume
  lan78xx: Fix race conditions in suspend/resume handling

Juhee Kang (1):
  hv_netvsc: use netif_is_bond_master() instead of open code

Lena Wang (1):
  netfilter: nf_conntrack_h323: Add protection for bmp length out of
    range

Long Li (2):
  hv_netvsc: Wait for completion on request SWITCH_DATA_PATH
  hv_netvsc: Process NETDEV_GOING_DOWN on VF hot remove

Maciej Fijalkowski (2):
  ixgbe: {dis, en}able irqs in ixgbe_txrx_ring_{dis, en}able
  i40e: disable NAPI right after disabling irqs when handling xsk_pool

Marek Vasut (1):
  regmap: Add bulk read/write callbacks into regmap_config

Martin KaFai Lau (2):
  net: Change sock_getsockopt() to take the sk ptr instead of the sock
    ptr
  bpf: net: Change sk_getsockopt() to take the sockptr_t argument

Mathias Nyman (3):
  xhci: remove extra loop in interrupt context
  xhci: prevent double-fetch of transfer and transfer event TRBs
  xhci: process isoc TD properly when there was a transaction error mid
    TD.

Michal Pecio (1):
  xhci: handle isoc Babble and Buffer Overrun events properly

Mike Kravetz (1):
  mm/hugetlb: change hugetlb_reserve_pages() to type bool

Muhammad Usama Anjum (1):
  selftests/mm: switch to bash from sh

Nico Pache (1):
  selftests: mm: fix map_hugetlb failure on 64K page size systems

Oleg Nesterov (5):
  getrusage: add the "signal_struct *sig" local variable
  getrusage: move thread_group_cputime_adjusted() outside of
    lock_task_sighand()
  getrusage: use __for_each_thread()
  getrusage: use sig->stats_lock rather than lock_task_sighand()
  exit: wait_task_zombie: kill the no longer necessary
    spin_lock_irq(siglock)

Oleksij Rempel (1):
  net: lan78xx: fix runtime PM count underflow on link stop

Ondrej Mosnacek (1):
  lsm: fix default return value of the socket_getpeersec_*() hooks

Paul Moore (1):
  lsm: make security_socket_getpeersec_stream() sockptr_t safe

Prakash Sangappa (1):
  mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE

Rand Deeb (1):
  net: ice: Fix potential NULL pointer dereference in
    ice_bridge_setlink()

Sasha Levin (1):
  Linux 5.10.213-rc1

Shradha Gupta (1):
  hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed

Steven Rostedt (Google) (1):
  tracing/net_sched: Fix tracepoints that save qdisc_dev() as a string

Toke Høiland-Jørgensen (1):
  cpumap: Zero-initialise xdp_rxq_info struct before running XDP program

Yann Gautier (1):
  mmc: mmci: stm32: use a buffer for unaligned DMA requests

Zhang Yi (2):
  ext4: refactor ext4_da_map_blocks()
  ext4: convert to exclusive lock while inserting delalloc extents

 Makefile                                      |   4 +-
 arch/um/Kconfig                               |  13 +
 arch/um/Makefile                              |   3 +-
 arch/x86/Makefile.um                          |   2 +-
 drivers/base/regmap/internal.h                |   4 +
 drivers/base/regmap/regmap.c                  |  77 +-
 drivers/hv/channel.c                          | 174 +++-
 drivers/hv/hyperv_vmbus.h                     |   3 +-
 drivers/hv/ring_buffer.c                      |  28 +-
 drivers/mmc/host/mmci_stm32_sdmmc.c           | 112 ++-
 drivers/net/ethernet/intel/i40e/i40e_main.c   |   2 +-
 drivers/net/ethernet/intel/ice/ice_main.c     |   2 +
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |  56 +-
 drivers/net/geneve.c                          |  18 +-
 drivers/net/hyperv/hyperv_net.h               |  13 +
 drivers/net/hyperv/netvsc.c                   |  55 +-
 drivers/net/hyperv/netvsc_drv.c               | 107 +-
 drivers/net/hyperv/rndis_filter.c             |   1 +
 drivers/net/usb/lan78xx.c                     | 910 ++++++++++++++----
 drivers/tty/serial/Kconfig                    |   1 +
 drivers/tty/serial/max310x.c                  | 378 ++++++--
 drivers/usb/host/xhci-ring.c                  | 143 ++-
 drivers/usb/host/xhci.h                       |   3 +
 fs/ext4/extents.c                             |   5 +-
 fs/ext4/extents_status.c                      |  14 +-
 fs/ext4/extents_status.h                      |   6 +-
 fs/ext4/inode.c                               |  65 +-
 fs/hugetlbfs/inode.c                          |  17 +-
 include/linux/filter.h                        |   3 +-
 include/linux/hugetlb.h                       |   2 +-
 include/linux/hyperv.h                        |  23 +
 include/linux/lsm_hook_defs.h                 |   6 +-
 include/linux/lsm_hooks.h                     |   4 +-
 include/linux/regmap.h                        |  19 +
 include/linux/security.h                      |  11 +-
 include/linux/sockptr.h                       |   5 +
 include/trace/events/qdisc.h                  |  20 +-
 kernel/bpf/cpumap.c                           |   2 +-
 kernel/exit.c                                 |  12 +-
 kernel/sys.c                                  |  91 +-
 mm/hugetlb.c                                  |  37 +-
 net/core/filter.c                             |   5 +-
 net/core/sock.c                               |  52 +-
 net/ipv6/route.c                              |  21 +-
 net/netfilter/nf_conntrack_h323_asn1.c        |   4 +
 net/netfilter/nft_ct.c                        |  11 +-
 net/netrom/af_netrom.c                        |  14 +-
 net/netrom/nr_dev.c                           |   2 +-
 net/netrom/nr_in.c                            |   6 +-
 net/netrom/nr_out.c                           |   2 +-
 net/netrom/nr_route.c                         |   8 +-
 net/netrom/nr_subr.c                          |   5 +-
 net/rds/rdma.c                                |   3 +
 net/rds/send.c                                |   6 +-
 security/apparmor/lsm.c                       |  29 +-
 security/security.c                           |  35 +-
 security/selinux/hooks.c                      |  13 +-
 security/smack/smack_lsm.c                    |  19 +-
 .../selftests/vm/charge_reserved_hugetlb.sh   |   2 +-
 tools/testing/selftests/vm/map_hugetlb.c      |   7 +
 .../selftests/vm/write_hugetlb_memory.sh      |   2 +-
 61 files changed, 1986 insertions(+), 711 deletions(-)

-- 
2.43.0

Hi!

> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y

Tested-by: Pavel Machek (CIP) <pavel@denx.de>

Best regards,
                                                                Pavel


-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Hello!

On 13/03/24 10:45 a. m., Sasha Levin wrote:
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>          https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> or in the git tree and branch at:
>          git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
> 
> Thanks,
> Sasha

We're seeing regressions while building PowerPC with GCC 8 and 12 with ppc6xx_defconfig:

-----8<-----
   /builds/linux/drivers/macintosh/via-pmu-backlight.c:22:20: error: 'FB_BACKLIGHT_LEVELS' undeclared here (not in a function)
      22 | static u8 bl_curve[FB_BACKLIGHT_LEVELS];
         |                    ^~~~~~~~~~~~~~~~~~~
   In file included from /builds/linux/include/linux/kernel.h:15,
                    from /builds/linux/include/asm-generic/bug.h:20,
                    from /builds/linux/arch/powerpc/include/asm/bug.h:109,
                    from /builds/linux/include/linux/bug.h:5,
                    from /builds/linux/include/linux/thread_info.h:12,
                    from /builds/linux/arch/powerpc/include/asm/ptrace.h:264,
                    from /builds/linux/drivers/macintosh/via-pmu-backlight.c:11:
----->8-----

Bisection points to:

   commit ee550f669e91c4cb0c884f38aa915497bc201585
   Author: Thomas Zimmermann <tzimmermann@suse.de>
   Date:   Wed Mar 6 13:28:20 2024 +0100
       arch/powerpc: Remove <linux/fb.h> from backlight code


Reverting that commit made the build pass again.

Reproducer:

   tuxmake --runtime podman --target-arch powerpc --toolchain gcc-12 --kconfig ppc6xx_defconfig

Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>


Greetings!

Daniel Díaz
daniel.diaz@linaro.org

On Mon, 25 Mar 2024 at 00:55, Daniel Díaz <daniel.diaz@linaro.org> wrote:
> Hello!
>
> On 13/03/24 10:45 a. m., Sasha Levin wrote:
> > This is the start of the stable review cycle for the 5.10.213 release.
> > There are 73 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >          https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> > or in the git tree and branch at:
> >          git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> > and the diffstat can be found below.
> >
> > Thanks,
> > Sasha
>
> We're seeing regressions while building PowerPC with GCC 8 and 12 with ppc6xx_defconfig:
>
> -----8<-----
>    /builds/linux/drivers/macintosh/via-pmu-backlight.c:22:20: error: 'FB_BACKLIGHT_LEVELS' undeclared here (not in a function)
>       22 | static u8 bl_curve[FB_BACKLIGHT_LEVELS];
>          |                    ^~~~~~~~~~~~~~~~~~~
>    In file included from /builds/linux/include/linux/kernel.h:15,
>                     from /builds/linux/include/asm-generic/bug.h:20,
>                     from /builds/linux/arch/powerpc/include/asm/bug.h:109,
>                     from /builds/linux/include/linux/bug.h:5,
>                     from /builds/linux/include/linux/thread_info.h:12,
>                     from /builds/linux/arch/powerpc/include/asm/ptrace.h:264,
>                     from /builds/linux/drivers/macintosh/via-pmu-backlight.c:11:
> ----->8-----
>
> Bisection points to:
>
>    commit ee550f669e91c4cb0c884f38aa915497bc201585
>    Author: Thomas Zimmermann <tzimmermann@suse.de>
>    Date:   Wed Mar 6 13:28:20 2024 +0100
>        arch/powerpc: Remove <linux/fb.h> from backlight code
>
>
> Reverting that commit made the build pass again.
>
> Reproducer:
>
>    tuxmake --runtime podman --target-arch powerpc --toolchain gcc-12 --kconfig ppc6xx_defconfig
>
> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
>
> Greetings!
>
> Daniel Díaz
> daniel.diaz@linaro.org

Apologies for replying to the wrong email here -- it should have been
for 5.10.214-rc1. Naresh took care of relaying the information to the
right place.

-- 
ddiaz

Hi!

> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.

> Ondrej Mosnacek (1):
>   lsm: fix default return value of the socket_getpeersec_*() hooks

I don't see this one in 6.1. 

> Zhang Yi (2):
>   ext4: convert to exclusive lock while inserting delalloc extents

I don't see this one in 6.1.

> Marek Vasut (1):
>   regmap: Add bulk read/write callbacks into regmap_config

This one quite intrusive for the stable. Plus, at least "regmap: Add
missing map->bus check" is marked as fixing this one.

Best regards,
								Pavel

-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On 3/20/24 2:41 PM, Pavel Machek wrote:

>> Marek Vasut (1):
>>    regmap: Add bulk read/write callbacks into regmap_config
> 
> This one quite intrusive for the stable. Plus, at least "regmap: Add
> missing map->bus check" is marked as fixing this one.

If there is no very good reason to include that regmap patch in stable 
backports, I would skip it, it is a feature patch. Does any backport 
depend on it ?

Hi!

> > > Marek Vasut (1):
> > >    regmap: Add bulk read/write callbacks into regmap_config
> > 
> > This one quite intrusive for the stable. Plus, at least "regmap: Add
> > missing map->bus check" is marked as fixing this one.
> 
> If there is no very good reason to include that regmap patch in stable
> backports, I would skip it, it is a feature patch. Does any backport depend
> on it ?

Well, yes and no.

Series of max310x patches depends on it:

!!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max
310x: use regmap methods for SPI batch operations

...

!! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched
operations

But according to the 3f42b1, the bug did not exist in 5.10 in the
first place, so we got buggy 285e76 backported, and then fixes up-to
3f42b1 applied to fix it up.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On 3/22/24 10:48 AM, Pavel Machek wrote:
> Hi!
> 
>>>> Marek Vasut (1):
>>>>     regmap: Add bulk read/write callbacks into regmap_config
>>>
>>> This one quite intrusive for the stable. Plus, at least "regmap: Add
>>> missing map->bus check" is marked as fixing this one.
>>
>> If there is no very good reason to include that regmap patch in stable
>> backports, I would skip it, it is a feature patch. Does any backport depend
>> on it ?
> 
> Well, yes and no.
> 
> Series of max310x patches depends on it:
> 
> !!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max
> 310x: use regmap methods for SPI batch operations
> 
> ...
> 
> !! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched
> operations
> 
> But according to the 3f42b1, the bug did not exist in 5.10 in the
> first place, so we got buggy 285e76 backported, and then fixes up-to
> 3f42b1 applied to fix it up.

Then probably both max30x patches should be dropped/reverted and the 
regmap bulk callbacks also dropped ?

Hi!

> > > > > Marek Vasut (1):
> > > > >     regmap: Add bulk read/write callbacks into regmap_config
> > > > 
> > > > This one quite intrusive for the stable. Plus, at least "regmap: Add
> > > > missing map->bus check" is marked as fixing this one.
> > > 
> > > If there is no very good reason to include that regmap patch in stable
> > > backports, I would skip it, it is a feature patch. Does any backport depend
> > > on it ?
> > 
> > Well, yes and no.
> > 
> > Series of max310x patches depends on it:
> > 
> > !!a just a preparation; buggy, whole series for fixing this |ef8537927 285e76 o: 5.10| serial: max
> > 310x: use regmap methods for SPI batch operations
> > 
> > ...
> > 
> > !! whole series to fix corruption, which did not exist in 5.10 in the first place |57871c388 3f42b1 o: 5.10| serial: max310x: fix IO data corruption in batched
> > operations
> > 
> > But according to the 3f42b1, the bug did not exist in 5.10 in the
> > first place, so we got buggy 285e76 backported, and then fixes up-to
> > 3f42b1 applied to fix it up.
> 
> Then probably both max30x patches should be dropped/reverted and the regmap
> bulk callbacks also dropped ?

Agreed.

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On Wednesday, March 13, 2024 22:15 IST, Sasha Levin <sashal@kernel.org> wrote:

> 
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>         https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
> 

KernelCI report for stable-rc/linux-5.10.y for this week.

## stable-rc HEAD for linux-5.10.y:
Date: 2024-03-13
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/?h=0a70dd1e1aa9dfe25d4647f86675dc6dac41631e

## Build failures:
No build failures seen for the stable-rc/linux-5.10.y commit head \o/

## Boot failures:
No **new** boot failures seen for the stable-rc/linux-5.10.y commit head \o/

Tested-by: kernelci.org bot <bot@kernelci.org>

Thanks,
Shreeya Patel

Hi Sasha,

On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
> 
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.

This one still has the problem with the documentation build and does
not yet include:

https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/

Can you pick it up as well?

Regards,
Salvatore

On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
>Hi Sasha,
>
>On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
>>
>> This is the start of the stable review cycle for the 5.10.213 release.
>> There are 73 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
>> Anything received after that time might be too late.
>
>This one still has the problem with the documentation build and does
>not yet include:
>
>https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
>
>Can you pick it up as well?

I'll pick it up for the next release cycle, thanks!

-- 
Thanks,
Sasha

Hi Sasha,

On Fri, Mar 15, 2024 at 02:39:37PM -0400, Sasha Levin wrote:
> On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
> > Hi Sasha,
> > 
> > On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
> > > 
> > > This is the start of the stable review cycle for the 5.10.213 release.
> > > There are 73 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > > 
> > > Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> > > Anything received after that time might be too late.
> > 
> > This one still has the problem with the documentation build and does
> > not yet include:
> > 
> > https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
> > 
> > Can you pick it up as well?
> 
> I'll pick it up for the next release cycle, thanks!

Did something went wrong here? I do not see in in the current review
for 5.10.214-rc2. Can you still pick it for 5.10.214 to get
documentation build working?

Thanks a lot already,

Regards,
Salvatore

On Tue, Mar 26, 2024 at 07:59:31AM +0100, Salvatore Bonaccorso wrote:
> Hi Sasha,
> 
> On Fri, Mar 15, 2024 at 02:39:37PM -0400, Sasha Levin wrote:
> > On Thu, Mar 14, 2024 at 10:47:19PM +0100, Salvatore Bonaccorso wrote:
> > > Hi Sasha,
> > > 
> > > On Wed, Mar 13, 2024 at 12:45:27PM -0400, Sasha Levin wrote:
> > > > 
> > > > This is the start of the stable review cycle for the 5.10.213 release.
> > > > There are 73 patches in this series, all will be posted as a response
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > > 
> > > > Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> > > > Anything received after that time might be too late.
> > > 
> > > This one still has the problem with the documentation build and does
> > > not yet include:
> > > 
> > > https://lore.kernel.org/regressions/ZeZAHnzlmZoAhkqW@eldamar.lan/
> > > 
> > > Can you pick it up as well?
> > 
> > I'll pick it up for the next release cycle, thanks!
> 
> Did something went wrong here? I do not see in in the current review
> for 5.10.214-rc2. Can you still pick it for 5.10.214 to get
> documentation build working?

Sorry for the delay, tried to have a vacation :)

Now queued up.

greg k-h

On 3/13/24 09:45, Sasha Levin wrote:
> 
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>          https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> or in the git tree and branch at:
>          git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
> 
> Thanks,
> Sasha

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on 
BMIPS_GENERIC:

Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
-- 
Florian

On Wed, 13 Mar 2024 at 22:16, Sasha Levin <sashal@kernel.org> wrote:
>
>
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Mar 15 04:46:39 PM UTC 2024.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> Thanks,
> Sasha


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>

## Build
* kernel: 5.10.213-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 0a70dd1e1aa9dfe25d4647f86675dc6dac41631e
* git describe: v5.10.212-73-g0a70dd1e1aa9
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.212-73-g0a70dd1e1aa9

## Test Regressions (compared to v5.10.212)

## Metric Regressions (compared to v5.10.212)

## Test Fixes (compared to v5.10.212)

## Metric Fixes (compared to v5.10.212)

## Test result summary
total: 73104, pass: 57812, fail: 1619, skip: 13626, xfail: 47

## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 107 total, 107 passed, 0 failed
* arm64: 33 total, 33 passed, 0 failed
* i386: 28 total, 28 passed, 0 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 25 total, 25 passed, 0 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 30 total, 30 passed, 0 failed

## Test suites summary
* boot
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-exec
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-crypto
* ltp-cve
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-smoketest
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture

--
Linaro LKFT
https://lkft.linaro.org

Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

Thanks Sasha for submitting a stable rc review!

If it's not too much trouble, would it be possible to have a different
header in the 00 patch from the other patches for my mailbox?
The mails Greg sends have the X-KernelTest-* headers (patch, tree,
branch etc) only in the cover letter, while all the patches themselves
only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'

I don't really care much what actual tags are on which as long as
there's a way to differentiate that cover letter from the rest so I can
redirect it to a mailbox I actually read to notice there's a new rc to
test, without having all the patches unless I explicitly look for them.

If it's difficult I'll add a regex on the subject for ' 00/' or
something, I'd prefer matching only headers for robustness but just let
me know.


Didn't run into any problem with the patches themselves:

> The whole patch series can be found in one patch at:
>         https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.10.y&id2=v5.10.212
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.

Tested 0a70dd1e1aa9 ("Linux 5.10.213-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)

No obvious regression in dmesg or basic tests:
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>

-- 
Dominique Martinet | Asmadeus

On Thu, Mar 14, 2024 at 04:03:25PM +0900, Dominique Martinet wrote:
>Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
>> This is the start of the stable review cycle for the 5.10.213 release.
>> There are 73 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>
>Thanks Sasha for submitting a stable rc review!
>
>If it's not too much trouble, would it be possible to have a different
>header in the 00 patch from the other patches for my mailbox?
>The mails Greg sends have the X-KernelTest-* headers (patch, tree,
>branch etc) only in the cover letter, while all the patches themselves
>only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'
>
>I don't really care much what actual tags are on which as long as
>there's a way to differentiate that cover letter from the rest so I can
>redirect it to a mailbox I actually read to notice there's a new rc to
>test, without having all the patches unless I explicitly look for them.
>
>If it's difficult I'll add a regex on the subject for ' 00/' or
>something, I'd prefer matching only headers for robustness but just let
>me know.

I should be able to adjust my scripts to match what Greg does. Thanks
for pointing it out!

-- 
Thanks,
Sasha

Hello!

On Thu, 14 Mar 2024 at 01:03, Dominique Martinet <asmadeus@codewreck.org> wrote:
> Sasha Levin wrote on Wed, Mar 13, 2024 at 12:45:27PM -0400:
> > This is the start of the stable review cycle for the 5.10.213 release.
> > There are 73 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
>
> Thanks Sasha for submitting a stable rc review!
>
> If it's not too much trouble, would it be possible to have a different
> header in the 00 patch from the other patches for my mailbox?
> The mails Greg sends have the X-KernelTest-* headers (patch, tree,
> branch etc) only in the cover letter, while all the patches themselves
> only have 'X-stable: review' and 'X-Patchwork-Hint: ignore'
>
> I don't really care much what actual tags are on which as long as
> there's a way to differentiate that cover letter from the rest so I can
> redirect it to a mailbox I actually read to notice there's a new rc to
> test, without having all the patches unless I explicitly look for them.

I subscribe to this request. We ran into unexpected issues because all
the emails in the series included the same headers as the cover.

> If it's difficult I'll add a regex on the subject for ' 00/' or
> something, I'd prefer matching only headers for robustness but just let
> me know.

That's what I ended up doing, and you know the saying: I had this
problem and solved it via regexes, now I have two problems. :) FWIW,
here's my "problem":
  '^Subject: \[PATCH\ [456]\.[0-9]+\ 0[0]*\/'

Greetings!


Daniel Díaz
daniel.diaz@linaro.org

Hi!

> This is the start of the stable review cycle for the 5.10.213 release.
> There are 73 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

While debugging "search for known-bad commit" script, I noticed:

We have

41b3cc57d626d c2e39305299f0 btrfs: clear extent buffer uptodate when
we fail to write it

commit in 5.10, which is fixed by this, but we don't have that one:

651740a502411 btrfs: check WRITE_ERR when trying to read an extent
buffer

Best regards,
								Pavel
-- 
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

On Wed, Mar 20, 2024 at 02:44:06PM +0100, Pavel Machek wrote:
>Hi!
>
>> This is the start of the stable review cycle for the 5.10.213 release.
>> There are 73 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>
>While debugging "search for known-bad commit" script, I noticed:
>
>We have
>
>41b3cc57d626d c2e39305299f0 btrfs: clear extent buffer uptodate when
>we fail to write it
>
>commit in 5.10, which is fixed by this, but we don't have that one:
>
>651740a502411 btrfs: check WRITE_ERR when trying to read an extent
>buffer

Hey Pavel,

There are two reasons it didn't make it into 5.10 or 5.4:

1. It doesn't build on any of those kernels, and we haven't gotten a
backport we could apply.

2. There's a follow-up fix that happened soon after ( 40cdc509877b
("btrfs: skip reserved bytes warning on unmount after log cleanup
failure") ) which needs a backport on it's own.


-- 
Thanks,
Sasha