[PATCH 5.15 00/23] 5.15.160-rc1 review

[PATCH 5.15 00/23] 5.15.160-rc1 review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 5.15.160 release.
There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
or in the git tree and branch at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 5.15.160-rc1

Akira Yokosawa <akiyks@gmail.com>
    docs: kernel_include.py: Cope with docutils 0.21

Thomas Weißschuh <linux@weissschuh.net>
    admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET

Jarkko Sakkinen <jarkko@kernel.org>
    KEYS: trusted: Do not use WARN when encode fails

AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    remoteproc: mediatek: Make sure IPI buffer fits in L2TCM

Daniel Thompson <daniel.thompson@linaro.org>
    serial: kgdboc: Fix NMI-safety problems from keyboard reset code

Heikki Krogerus <heikki.krogerus@linux.intel.com>
    usb: typec: ucsi: displayport: Fix potential deadlock

Carlos Llamas <cmllamas@google.com>
    binder: fix max_thread type inconsistency

Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
    drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()

Sean Christopherson <seanjc@google.com>
    KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection

Eric Dumazet <edumazet@google.com>
    netlink: annotate data-races around sk->sk_err

Eric Dumazet <edumazet@google.com>
    netlink: annotate lockless accesses to nlk->max_recvmsg_len

Jakub Kicinski <kuba@kernel.org>
    net: tls: handle backlogging of crypto requests

Jakub Kicinski <kuba@kernel.org>
    tls: fix race between async notify and socket close

Jakub Kicinski <kuba@kernel.org>
    net: tls: factor out tls_*crypt_async_wait()

Sabrina Dubroca <sd@queasysnail.net>
    tls: extract context alloc/initialization out of tls_set_sw_offload

Jakub Kicinski <kuba@kernel.org>
    tls: rx: simplify async wait

Doug Berger <opendmb@gmail.com>
    net: bcmgenet: synchronize UMAC_CMD access

Doug Berger <opendmb@gmail.com>
    net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access

Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems"

Jarkko Sakkinen <jarkko@kernel.org>
    KEYS: trusted: Fix memory leak in tpm2_key_encode()

NeilBrown <neilb@suse.de>
    nfsd: don't allow nfsd threads to be signalled.

Sergey Shtylyov <s.shtylyov@omp.ru>
    pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()

Jose Fernandez <josef@netflix.com>
    drm/amd/display: Fix division by zero in setup_dsc_config


-------------

Diffstat:

 .../admin-guide/hw-vuln/core-scheduling.rst        |   4 +-
 Documentation/sphinx/kernel_include.py             |   1 -
 Makefile                                           |   4 +-
 arch/x86/kvm/x86.c                                 |  11 +-
 drivers/android/binder.c                           |   2 +-
 drivers/android/binder_internal.h                  |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c            |   3 +
 drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c        |   7 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.c     |  12 +-
 drivers/net/ethernet/broadcom/genet/bcmgenet.h     |   2 +
 drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c |   6 +
 drivers/net/ethernet/broadcom/genet/bcmmii.c       |   4 +
 drivers/pinctrl/core.c                             |  14 +-
 drivers/remoteproc/mtk_scp.c                       |  10 +-
 drivers/tty/serial/kgdboc.c                        |  30 +++-
 drivers/usb/typec/ucsi/displayport.c               |   4 -
 fs/nfs/callback.c                                  |   9 +-
 fs/nfsd/nfs4proc.c                                 |   5 +-
 fs/nfsd/nfssvc.c                                   |  12 --
 include/net/tls.h                                  |   6 -
 net/netlink/af_netlink.c                           |  23 +--
 net/sunrpc/svc_xprt.c                              |  16 +-
 net/tls/tls_sw.c                                   | 199 +++++++++++----------
 security/keys/trusted-keys/trusted_tpm2.c          |  25 ++-
 tools/testing/selftests/vm/map_hugetlb.c           |   7 -
 25 files changed, 243 insertions(+), 175 deletions(-)

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[SeongJae Park]

Hello,

On Thu, 23 May 2024 15:12:56 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.

This rc kernel passes DAMON functionality test[1] on my test machine.
Attaching the test results summary below.  Please note that I retrieved the
kernel from linux-stable-rc tree[2].

Tested-by: SeongJae Park <sj@kernel.org>

[1] https://github.com/awslabs/damon-tests/tree/next/corr
[2] 0aee1934e6e2 ("Linux 5.15.160-rc1")

Thanks,
SJ

[...]

---

ok 1 selftests: damon: debugfs_attrs.sh
ok 1 selftests: damon-tests: kunit.sh
ok 2 selftests: damon-tests: huge_count_read_write.sh
ok 3 selftests: damon-tests: buffer_overflow.sh
ok 4 selftests: damon-tests: rm_contexts.sh
ok 5 selftests: damon-tests: record_null_deref.sh
ok 6 selftests: damon-tests: dbgfs_target_ids_read_before_terminate_race.sh
ok 7 selftests: damon-tests: dbgfs_target_ids_pid_leak.sh
ok 8 selftests: damon-tests: damo_tests.sh
ok 9 selftests: damon-tests: masim-record.sh
ok 10 selftests: damon-tests: build_i386.sh
ok 11 selftests: damon-tests: build_arm64.sh
ok 12 selftests: damon-tests: build_m68k.sh
ok 13 selftests: damon-tests: build_i386_idle_flag.sh
ok 14 selftests: damon-tests: build_i386_highpte.sh
ok 15 selftests: damon-tests: build_nomemcg.sh
 [33m
 [92mPASS [39m

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

On Thu, May 23, 2024 at 03:12:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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.

Tested-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Florian Fainelli]

On 5/23/24 06:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

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

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Harshit Mogalapalli]

Hi Greg,

On 23/05/24 18:42, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 

No problems seen on x86_64 and aarch64 with our testing.

Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

Thanks,
Harshit


> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Anders Roxell]

On Thu, 23 May 2024 at 15:19, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>         https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
>         git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.

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 Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 102 total, 102 passed, 0 failed
* arm64: 31 total, 31 passed, 0 failed
* i386: 25 total, 25 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* parisc: 3 total, 3 passed, 0 failed
* powerpc: 24 total, 24 passed, 0 failed
* riscv: 8 total, 8 passed, 0 failed
* s390: 9 total, 9 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 27 total, 27 passed, 0 failed

## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mm
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-watchdog
* kselftest-x86
* kselftest-zram
* 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

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Shuah Khan]

On 5/23/24 07:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Ron Economos]

On 5/23/24 6:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Built and booted successfully on RISC-V RV64 (HiFive Unmatched).

Tested-by: Ron Economos <re@w6rz.net>

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Jon Hunter]

Hi Greg,

On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> or in the git tree and branch at:
> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -------------
> Pseudo-Shortlog of commits:

...

> NeilBrown <neilb@suse.de>
>      nfsd: don't allow nfsd threads to be signalled.


I am seeing a suspend regression on a couple boards and bisect is 
pointing to the above commit. Reverting this commit does fix the issue.

Test results for stable-v5.15:
     10 builds:	10 pass, 0 fail
     26 boots:	26 pass, 0 fail
     102 tests:	100 pass, 2 fail

Linux version:	5.15.160-rc1-g7c7f29d3b2af
Boards tested:	tegra124-jetson-tk1, tegra186-p2771-0000,
                 tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
                 tegra20-ventana, tegra210-p2371-2180,
                 tegra210-p3450-0000, tegra30-cardhu-a04

Test failures:	tegra186-p2771-0000: pm-system-suspend.sh
                 tegra194-p2972-0000: pm-system-suspend.sh

Jon

-- 
nvpublic

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Kelsey Steele]

On Thu, May 23, 2024 at 03:12:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.15.160 release.
> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> Anything received after that time might be too late.
> 
No regressions found on WSL (x86 and arm64).

Built, booted, and reviewed dmesg.

Thank you. :)

Tested-by: Kelsey Steele <kelseysteele@linux.microsoft.com> 

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Greg Kroah-Hartman]

On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
> Hi Greg,
> 
> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.15.160 release.
> > There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> > or in the git tree and branch at:
> > 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > -------------
> > Pseudo-Shortlog of commits:
> 
> ...
> 
> > NeilBrown <neilb@suse.de>
> >      nfsd: don't allow nfsd threads to be signalled.
> 
> 
> I am seeing a suspend regression on a couple boards and bisect is pointing
> to the above commit. Reverting this commit does fix the issue.

Ugh, that fixes the report from others.  Can you cc: everyone on that
and figure out what is going on, as this keeps going back and forth...

thanks,

greg k-h

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Jon Hunter]

On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>> Hi Greg,
>>
>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.15.160 release.
>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>> Anything received after that time might be too late.
>>>
>>> The whole patch series can be found in one patch at:
>>> 	https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>> or in the git tree and branch at:
>>> 	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>> -------------
>>> Pseudo-Shortlog of commits:
>>
>> ...
>>
>>> NeilBrown <neilb@suse.de>
>>>       nfsd: don't allow nfsd threads to be signalled.
>>
>>
>> I am seeing a suspend regression on a couple boards and bisect is pointing
>> to the above commit. Reverting this commit does fix the issue.
> 
> Ugh, that fixes the report from others.  Can you cc: everyone on that
> and figure out what is going on, as this keeps going back and forth...


Adding Chuck, Neil and Chris from the bug report here [0].

With the above applied to v5.15.y, I am seeing suspend on 2 of our 
boards fail. These boards are using NFS and on entry to suspend I am now 
seeing ...

  Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
  freeze, wq_busy=0):

The boards appear to hang at that point. So may be something else missing?

Jon

[0] 
https://lore.kernel.org/lkml/b363e394-7549-4b9e-b71b-d97cd13f9607@alliedtelesis.co.nz/

-- 
nvpublic

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever III]

> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> 
> 
> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>> Hi Greg,
>>> 
>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 5.15.160 release.
>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>> Anything received after that time might be too late.
>>>> 
>>>> The whole patch series can be found in one patch at:
>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>> or in the git tree and branch at:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>>> and the diffstat can be found below.
>>>> 
>>>> thanks,
>>>> 
>>>> greg k-h
>>>> 
>>>> -------------
>>>> Pseudo-Shortlog of commits:
>>> 
>>> ...
>>> 
>>>> NeilBrown <neilb@suse.de>
>>>>      nfsd: don't allow nfsd threads to be signalled.
>>> 
>>> 
>>> I am seeing a suspend regression on a couple boards and bisect is pointing
>>> to the above commit. Reverting this commit does fix the issue.
>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>> and figure out what is going on, as this keeps going back and forth...
> 
> 
> Adding Chuck, Neil and Chris from the bug report here [0].
> 
> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
> 
> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
> freeze, wq_busy=0):
> 
> The boards appear to hang at that point. So may be something else missing?

Note that we don't have access to hardware like this, so
we haven't tested that patch (even the upstream version)
with suspend on that hardware.

So, it could be something missing, or it could be that
patch has a problem.

It would help us to know if you observe the same issue
with an upstream kernel, if that is possible.


> Jon
> 
> [0] https://lore.kernel.org/lkml/b363e394-7549-4b9e-b71b-d97cd13f9607@alliedtelesis.co.nz/
> 
> -- 
> nvpublic

--
Chuck Lever

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Jon Hunter]

On 28/05/2024 14:14, Chuck Lever III wrote:
> 
> 
>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>
>>
>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>> Hi Greg,
>>>>
>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.15.160 release.
>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>>> The whole patch series can be found in one patch at:
>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>>> or in the git tree and branch at:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>>>> and the diffstat can be found below.
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>>
>>>>> -------------
>>>>> Pseudo-Shortlog of commits:
>>>>
>>>> ...
>>>>
>>>>> NeilBrown <neilb@suse.de>
>>>>>       nfsd: don't allow nfsd threads to be signalled.
>>>>
>>>>
>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
>>>> to the above commit. Reverting this commit does fix the issue.
>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>>> and figure out what is going on, as this keeps going back and forth...
>>
>>
>> Adding Chuck, Neil and Chris from the bug report here [0].
>>
>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
>>
>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>> freeze, wq_busy=0):
>>
>> The boards appear to hang at that point. So may be something else missing?
> 
> Note that we don't have access to hardware like this, so
> we haven't tested that patch (even the upstream version)
> with suspend on that hardware.


No problem, I would not expect you to have this particular hardware :-)

> So, it could be something missing, or it could be that
> patch has a problem.
> 
> It would help us to know if you observe the same issue
> with an upstream kernel, if that is possible.


I don't observe this with either mainline, -next or any other stable 
branch. So that would suggest that something else is missing from 
linux-5.15.y.

Jon

-- 
nvpublic

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chris Packham]

On 29/05/24 02:18, Jon Hunter wrote:
>
> On 28/05/2024 14:14, Chuck Lever III wrote:
>>
>>
>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>
>>>
>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>>> Hi Greg,
>>>>>
>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>>> This is the start of the stable review cycle for the 5.15.160 
>>>>>> release.
>>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>>>> Anything received after that time might be too late.
>>>>>>
>>>>>> The whole patch series can be found in one patch at:
>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz 
>>>>>>
>>>>>> or in the git tree and branch at:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
>>>>>> linux-5.15.y
>>>>>> and the diffstat can be found below.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>>>
>>>>>> -------------
>>>>>> Pseudo-Shortlog of commits:
>>>>>
>>>>> ...
>>>>>
>>>>>> NeilBrown <neilb@suse.de>
>>>>>>       nfsd: don't allow nfsd threads to be signalled.
>>>>>
>>>>>
>>>>> I am seeing a suspend regression on a couple boards and bisect is 
>>>>> pointing
>>>>> to the above commit. Reverting this commit does fix the issue.
>>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>>>> and figure out what is going on, as this keeps going back and forth...
>>>
>>>
>>> Adding Chuck, Neil and Chris from the bug report here [0].
>>>
>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our 
>>> boards fail. These boards are using NFS and on entry to suspend I am 
>>> now seeing ...
>>>
>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>>> freeze, wq_busy=0):
>>>
>>> The boards appear to hang at that point. So may be something else 
>>> missing?
>>
>> Note that we don't have access to hardware like this, so
>> we haven't tested that patch (even the upstream version)
>> with suspend on that hardware.
>
>
> No problem, I would not expect you to have this particular hardware :-)
>
It's probably not much help but for the oops I originally reported we've 
been carrying "nfsd: don't allow nfsd threads to be signalled" locally 
and that resolved it. Now that we've updated to 5.15.160 and dropped the 
local patch it's still resolved for us. Our systems don't make use of 
suspend so they won't hit any issue related to that.
>> So, it could be something missing, or it could be that
>> patch has a problem.
>>
>> It would help us to know if you observe the same issue
>> with an upstream kernel, if that is possible.
>
>
> I don't observe this with either mainline, -next or any other stable 
> branch. So that would suggest that something else is missing from 
> linux-5.15.y.
>
> Jon
>

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever III]

> On May 28, 2024, at 10:18 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> 
> 
> On 28/05/2024 14:14, Chuck Lever III wrote:
>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> 
>>> 
>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>>> Hi Greg,
>>>>> 
>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>>> This is the start of the stable review cycle for the 5.15.160 release.
>>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>>>> Anything received after that time might be too late.
>>>>>> 
>>>>>> The whole patch series can be found in one patch at:
>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>>>> or in the git tree and branch at:
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>>>>> and the diffstat can be found below.
>>>>>> 
>>>>>> thanks,
>>>>>> 
>>>>>> greg k-h
>>>>>> 
>>>>>> -------------
>>>>>> Pseudo-Shortlog of commits:
>>>>> 
>>>>> ...
>>>>> 
>>>>>> NeilBrown <neilb@suse.de>
>>>>>>      nfsd: don't allow nfsd threads to be signalled.
>>>>> 
>>>>> 
>>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
>>>>> to the above commit. Reverting this commit does fix the issue.
>>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>>>> and figure out what is going on, as this keeps going back and forth...
>>> 
>>> 
>>> Adding Chuck, Neil and Chris from the bug report here [0].
>>> 
>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
>>> 
>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>>> freeze, wq_busy=0):
>>> 
>>> The boards appear to hang at that point. So may be something else missing?
>> Note that we don't have access to hardware like this, so
>> we haven't tested that patch (even the upstream version)
>> with suspend on that hardware.
> 
> 
> No problem, I would not expect you to have this particular hardware :-)
> 
>> So, it could be something missing, or it could be that
>> patch has a problem.
>> It would help us to know if you observe the same issue
>> with an upstream kernel, if that is possible.
> 
> 
> I don't observe this with either mainline, -next or any other stable branch. So that would suggest that something else is missing from linux-5.15.y.

That helps. It would be very helpful to have a reproducer I can
use to confirm we have a fix. I'm sure this will be a process
that involves a non-trivial number of iterations.


--
Chuck Lever

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[NeilBrown]

On Wed, 29 May 2024, Chuck Lever III wrote:
> 
> 
> > On May 28, 2024, at 10:18 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> > 
> > 
> > On 28/05/2024 14:14, Chuck Lever III wrote:
> >>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>> 
> >>> 
> >>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
> >>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
> >>>>> Hi Greg,
> >>>>> 
> >>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
> >>>>>> This is the start of the stable review cycle for the 5.15.160 release.
> >>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> >>>>>> Anything received after that time might be too late.
> >>>>>> 
> >>>>>> The whole patch series can be found in one patch at:
> >>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> >>>>>> or in the git tree and branch at:
> >>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> >>>>>> and the diffstat can be found below.
> >>>>>> 
> >>>>>> thanks,
> >>>>>> 
> >>>>>> greg k-h
> >>>>>> 
> >>>>>> -------------
> >>>>>> Pseudo-Shortlog of commits:
> >>>>> 
> >>>>> ...
> >>>>> 
> >>>>>> NeilBrown <neilb@suse.de>
> >>>>>>      nfsd: don't allow nfsd threads to be signalled.
> >>>>> 
> >>>>> 
> >>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
> >>>>> to the above commit. Reverting this commit does fix the issue.
> >>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
> >>>> and figure out what is going on, as this keeps going back and forth...
> >>> 
> >>> 
> >>> Adding Chuck, Neil and Chris from the bug report here [0].
> >>> 
> >>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
> >>> 
> >>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
> >>> freeze, wq_busy=0):
> >>> 
> >>> The boards appear to hang at that point. So may be something else missing?
> >> Note that we don't have access to hardware like this, so
> >> we haven't tested that patch (even the upstream version)
> >> with suspend on that hardware.
> > 
> > 
> > No problem, I would not expect you to have this particular hardware :-)
> > 
> >> So, it could be something missing, or it could be that
> >> patch has a problem.
> >> It would help us to know if you observe the same issue
> >> with an upstream kernel, if that is possible.
> > 
> > 
> > I don't observe this with either mainline, -next or any other stable branch. So that would suggest that something else is missing from linux-5.15.y.
> 
> That helps. It would be very helpful to have a reproducer I can
> use to confirm we have a fix. I'm sure this will be a process
> that involves a non-trivial number of iterations.

Missing upstream patch is

Commit 9bd4161c5917 ("SUNRPC: change service idle list to be an llist")

This contains some freezer-related changes which probably should
have been a separate patch.

We probably just need to add "| TASK_FREEZABLE" in one or two places.
I'll post a patch for testing in a little while.

NeilBrown

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever III]

> On May 28, 2024, at 6:01 PM, NeilBrown <neilb@suse.de> wrote:
> 
> On Wed, 29 May 2024, Chuck Lever III wrote:
>> 
>> 
>>> On May 28, 2024, at 10:18 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> 
>>> 
>>> On 28/05/2024 14:14, Chuck Lever III wrote:
>>>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>> 
>>>>> 
>>>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>>>>> Hi Greg,
>>>>>>> 
>>>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>>>>> This is the start of the stable review cycle for the 5.15.160 release.
>>>>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>>>>>> Anything received after that time might be too late.
>>>>>>>> 
>>>>>>>> The whole patch series can be found in one patch at:
>>>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>>>>>> or in the git tree and branch at:
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>>>>>>> and the diffstat can be found below.
>>>>>>>> 
>>>>>>>> thanks,
>>>>>>>> 
>>>>>>>> greg k-h
>>>>>>>> 
>>>>>>>> -------------
>>>>>>>> Pseudo-Shortlog of commits:
>>>>>>> 
>>>>>>> ...
>>>>>>> 
>>>>>>>> NeilBrown <neilb@suse.de>
>>>>>>>>     nfsd: don't allow nfsd threads to be signalled.
>>>>>>> 
>>>>>>> 
>>>>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
>>>>>>> to the above commit. Reverting this commit does fix the issue.
>>>>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>>>>>> and figure out what is going on, as this keeps going back and forth...
>>>>> 
>>>>> 
>>>>> Adding Chuck, Neil and Chris from the bug report here [0].
>>>>> 
>>>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
>>>>> 
>>>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>>>>> freeze, wq_busy=0):
>>>>> 
>>>>> The boards appear to hang at that point. So may be something else missing?
>>>> Note that we don't have access to hardware like this, so
>>>> we haven't tested that patch (even the upstream version)
>>>> with suspend on that hardware.
>>> 
>>> 
>>> No problem, I would not expect you to have this particular hardware :-)
>>> 
>>>> So, it could be something missing, or it could be that
>>>> patch has a problem.
>>>> It would help us to know if you observe the same issue
>>>> with an upstream kernel, if that is possible.
>>> 
>>> 
>>> I don't observe this with either mainline, -next or any other stable branch. So that would suggest that something else is missing from linux-5.15.y.
>> 
>> That helps. It would be very helpful to have a reproducer I can
>> use to confirm we have a fix. I'm sure this will be a process
>> that involves a non-trivial number of iterations.
> 
> Missing upstream patch is
> 
> Commit 9bd4161c5917 ("SUNRPC: change service idle list to be an llist")
> 
> This contains some freezer-related changes which probably should
> have been a separate patch.

Thanks for tracking that down.


> We probably just need to add "| TASK_FREEZABLE" in one or two places.
> I'll post a patch for testing in a little while.

My understanding is that the stable maintainers prefer a backport
of a patch (or patches) that are already applied to Linus' tree.


--
Chuck Lever

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[NeilBrown]

On Wed, 29 May 2024, NeilBrown wrote:
> 
> We probably just need to add "| TASK_FREEZABLE" in one or two places.
> I'll post a patch for testing in a little while.

There is no TASK_FREEZABLE before v6.1.
This isn't due to a missed backport. It is simply because of differences
in the freezer in older kernels.

Please test this patch.

Thanks,
NeilBrown

From 416bd6ae9a598e64931d34b76aa58f39b11841cd Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Wed, 29 May 2024 09:38:22 +1000
Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:

Prior to v6.1, the freezer will only wake a kernel thread from an
uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
ignore it instead.

Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
Signed-off-by: NeilBrown <neilb@suse.de>
---
 net/sunrpc/svc_xprt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index b19592673eef..12e9293bd12b 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -764,10 +764,12 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
 	clear_bit(RQ_BUSY, &rqstp->rq_flags);
 	smp_mb__after_atomic();
 
+	freezer_do_not_count();
 	if (likely(rqst_should_sleep(rqstp)))
 		time_left = schedule_timeout(timeout);
 	else
 		__set_current_state(TASK_RUNNING);
+	freezer_count();
 
 	try_to_freeze();
 
-- 
2.44.0

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[NeilBrown]

On Wed, 29 May 2024, Chuck Lever III wrote:
> 
> 
> > On May 28, 2024, at 6:01 PM, NeilBrown <neilb@suse.de> wrote:
> > 
> > On Wed, 29 May 2024, Chuck Lever III wrote:
> >> 
> >> 
> >>> On May 28, 2024, at 10:18 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>> 
> >>> 
> >>> On 28/05/2024 14:14, Chuck Lever III wrote:
> >>>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> >>>>> 
> >>>>> 
> >>>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
> >>>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
> >>>>>>> Hi Greg,
> >>>>>>> 
> >>>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
> >>>>>>>> This is the start of the stable review cycle for the 5.15.160 release.
> >>>>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
> >>>>>>>> Anything received after that time might be too late.
> >>>>>>>> 
> >>>>>>>> The whole patch series can be found in one patch at:
> >>>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
> >>>>>>>> or in the git tree and branch at:
> >>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
> >>>>>>>> and the diffstat can be found below.
> >>>>>>>> 
> >>>>>>>> thanks,
> >>>>>>>> 
> >>>>>>>> greg k-h
> >>>>>>>> 
> >>>>>>>> -------------
> >>>>>>>> Pseudo-Shortlog of commits:
> >>>>>>> 
> >>>>>>> ...
> >>>>>>> 
> >>>>>>>> NeilBrown <neilb@suse.de>
> >>>>>>>>     nfsd: don't allow nfsd threads to be signalled.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
> >>>>>>> to the above commit. Reverting this commit does fix the issue.
> >>>>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
> >>>>>> and figure out what is going on, as this keeps going back and forth...
> >>>>> 
> >>>>> 
> >>>>> Adding Chuck, Neil and Chris from the bug report here [0].
> >>>>> 
> >>>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
> >>>>> 
> >>>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
> >>>>> freeze, wq_busy=0):
> >>>>> 
> >>>>> The boards appear to hang at that point. So may be something else missing?
> >>>> Note that we don't have access to hardware like this, so
> >>>> we haven't tested that patch (even the upstream version)
> >>>> with suspend on that hardware.
> >>> 
> >>> 
> >>> No problem, I would not expect you to have this particular hardware :-)
> >>> 
> >>>> So, it could be something missing, or it could be that
> >>>> patch has a problem.
> >>>> It would help us to know if you observe the same issue
> >>>> with an upstream kernel, if that is possible.
> >>> 
> >>> 
> >>> I don't observe this with either mainline, -next or any other stable branch. So that would suggest that something else is missing from linux-5.15.y.
> >> 
> >> That helps. It would be very helpful to have a reproducer I can
> >> use to confirm we have a fix. I'm sure this will be a process
> >> that involves a non-trivial number of iterations.
> > 
> > Missing upstream patch is
> > 
> > Commit 9bd4161c5917 ("SUNRPC: change service idle list to be an llist")
> > 
> > This contains some freezer-related changes which probably should
> > have been a separate patch.
> 
> Thanks for tracking that down.
> 
> 
> > We probably just need to add "| TASK_FREEZABLE" in one or two places.
> > I'll post a patch for testing in a little while.
> 
> My understanding is that the stable maintainers prefer a backport
> of a patch (or patches) that are already applied to Linus' tree.

They also preferred a full backport of fs/nfsd/..  That hasn't gone so
well :-)

In this case we would need 

Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")

to get TASK_FREEZABLE.
I doubt that would be a good choice.

NeilBrown


> 
> 
> --
> Chuck Lever
> 
> 
> 

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever III]

> On May 28, 2024, at 7:44 PM, NeilBrown <neilb@suse.de> wrote:
> 
> On Wed, 29 May 2024, Chuck Lever III wrote:
>> 
>> 
>>> On May 28, 2024, at 6:01 PM, NeilBrown <neilb@suse.de> wrote:
>>> 
>>> On Wed, 29 May 2024, Chuck Lever III wrote:
>>>> 
>>>> 
>>>>> On May 28, 2024, at 10:18 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>> 
>>>>> 
>>>>> On 28/05/2024 14:14, Chuck Lever III wrote:
>>>>>>> On May 28, 2024, at 5:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On 25/05/2024 15:20, Greg Kroah-Hartman wrote:
>>>>>>>> On Sat, May 25, 2024 at 12:13:28AM +0100, Jon Hunter wrote:
>>>>>>>>> Hi Greg,
>>>>>>>>> 
>>>>>>>>> On 23/05/2024 14:12, Greg Kroah-Hartman wrote:
>>>>>>>>>> This is the start of the stable review cycle for the 5.15.160 release.
>>>>>>>>>> There are 23 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 Sat, 25 May 2024 13:03:15 +0000.
>>>>>>>>>> Anything received after that time might be too late.
>>>>>>>>>> 
>>>>>>>>>> The whole patch series can be found in one patch at:
>>>>>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-rc1.gz
>>>>>>>>>> or in the git tree and branch at:
>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
>>>>>>>>>> and the diffstat can be found below.
>>>>>>>>>> 
>>>>>>>>>> thanks,
>>>>>>>>>> 
>>>>>>>>>> greg k-h
>>>>>>>>>> 
>>>>>>>>>> -------------
>>>>>>>>>> Pseudo-Shortlog of commits:
>>>>>>>>> 
>>>>>>>>> ...
>>>>>>>>> 
>>>>>>>>>> NeilBrown <neilb@suse.de>
>>>>>>>>>>    nfsd: don't allow nfsd threads to be signalled.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I am seeing a suspend regression on a couple boards and bisect is pointing
>>>>>>>>> to the above commit. Reverting this commit does fix the issue.
>>>>>>>> Ugh, that fixes the report from others.  Can you cc: everyone on that
>>>>>>>> and figure out what is going on, as this keeps going back and forth...
>>>>>>> 
>>>>>>> 
>>>>>>> Adding Chuck, Neil and Chris from the bug report here [0].
>>>>>>> 
>>>>>>> With the above applied to v5.15.y, I am seeing suspend on 2 of our boards fail. These boards are using NFS and on entry to suspend I am now seeing ...
>>>>>>> 
>>>>>>> Freezing of tasks failed after 20.002 seconds (1 tasks refusing to
>>>>>>> freeze, wq_busy=0):
>>>>>>> 
>>>>>>> The boards appear to hang at that point. So may be something else missing?
>>>>>> Note that we don't have access to hardware like this, so
>>>>>> we haven't tested that patch (even the upstream version)
>>>>>> with suspend on that hardware.
>>>>> 
>>>>> 
>>>>> No problem, I would not expect you to have this particular hardware :-)
>>>>> 
>>>>>> So, it could be something missing, or it could be that
>>>>>> patch has a problem.
>>>>>> It would help us to know if you observe the same issue
>>>>>> with an upstream kernel, if that is possible.
>>>>> 
>>>>> 
>>>>> I don't observe this with either mainline, -next or any other stable branch. So that would suggest that something else is missing from linux-5.15.y.
>>>> 
>>>> That helps. It would be very helpful to have a reproducer I can
>>>> use to confirm we have a fix. I'm sure this will be a process
>>>> that involves a non-trivial number of iterations.
>>> 
>>> Missing upstream patch is
>>> 
>>> Commit 9bd4161c5917 ("SUNRPC: change service idle list to be an llist")
>>> 
>>> This contains some freezer-related changes which probably should
>>> have been a separate patch.
>> 
>> Thanks for tracking that down.
>> 
>> 
>>> We probably just need to add "| TASK_FREEZABLE" in one or two places.
>>> I'll post a patch for testing in a little while.
>> 
>> My understanding is that the stable maintainers prefer a backport
>> of a patch (or patches) that are already applied to Linus' tree.
> 
> They also preferred a full backport of fs/nfsd/..  That hasn't gone so
> well :-)

Really? I count about 350 patches in the initial backport. Those patches
include nearly every NFSD patch from v5.16 up to the end of v6.2. We
agreed to stop once the filecache fixes had been applied; no-one asked
for a "full backport" from torvalds/HEAD.

Only two more patches have been applied since then. Three if you count
this one. All of these issues have been very narrow corner cases or
obscure test failures.

That is quite good, if you ask me. I don't see a problem, given the
monumental task and lack of NFSD stable testing infrastructure before
I began.


> In this case we would need 
> 
> Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
> 
> to get TASK_FREEZABLE.
> I doubt that would be a good choice.

I will let Greg and Sasha decide how they want to proceed, but it
would be wise to include this detail in your patch description.


--
Chuck Lever

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Jon Hunter]

On 29/05/2024 00:42, NeilBrown wrote:
> On Wed, 29 May 2024, NeilBrown wrote:
>>
>> We probably just need to add "| TASK_FREEZABLE" in one or two places.
>> I'll post a patch for testing in a little while.
> 
> There is no TASK_FREEZABLE before v6.1.
> This isn't due to a missed backport. It is simply because of differences
> in the freezer in older kernels.
> 
> Please test this patch.
> 
> Thanks,
> NeilBrown
> 
>  From 416bd6ae9a598e64931d34b76aa58f39b11841cd Mon Sep 17 00:00:00 2001
> From: NeilBrown <neilb@suse.de>
> Date: Wed, 29 May 2024 09:38:22 +1000
> Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
> 
> Prior to v6.1, the freezer will only wake a kernel thread from an
> uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
> IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
> ignore it instead.
> 
> Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>   net/sunrpc/svc_xprt.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index b19592673eef..12e9293bd12b 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -764,10 +764,12 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
>   	clear_bit(RQ_BUSY, &rqstp->rq_flags);
>   	smp_mb__after_atomic();
>   
> +	freezer_do_not_count();
>   	if (likely(rqst_should_sleep(rqstp)))
>   		time_left = schedule_timeout(timeout);
>   	else
>   		__set_current_state(TASK_RUNNING);
> +	freezer_count();
>   
>   	try_to_freeze();
>   


Thanks. I gave this a try on top of v5.15.160-rc1, but I am still seeing
the following and the board hangs ...

Freezing of tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):

So unfortunately this does not fix it :-(

Jon

-- 
nvpublic

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[NeilBrown]

On Wed, 29 May 2024, Jon Hunter wrote:
> On 29/05/2024 00:42, NeilBrown wrote:
> > On Wed, 29 May 2024, NeilBrown wrote:
> >>
> >> We probably just need to add "| TASK_FREEZABLE" in one or two places.
> >> I'll post a patch for testing in a little while.
> > 
> > There is no TASK_FREEZABLE before v6.1.
> > This isn't due to a missed backport. It is simply because of differences
> > in the freezer in older kernels.
> > 
> > Please test this patch.
> > 
> > Thanks,
> > NeilBrown
> > 
> >  From 416bd6ae9a598e64931d34b76aa58f39b11841cd Mon Sep 17 00:00:00 2001
> > From: NeilBrown <neilb@suse.de>
> > Date: Wed, 29 May 2024 09:38:22 +1000
> > Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
> > 
> > Prior to v6.1, the freezer will only wake a kernel thread from an
> > uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
> > IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
> > ignore it instead.
> > 
> > Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> >   net/sunrpc/svc_xprt.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index b19592673eef..12e9293bd12b 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -764,10 +764,12 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
> >   	clear_bit(RQ_BUSY, &rqstp->rq_flags);
> >   	smp_mb__after_atomic();
> >   
> > +	freezer_do_not_count();
> >   	if (likely(rqst_should_sleep(rqstp)))
> >   		time_left = schedule_timeout(timeout);
> >   	else
> >   		__set_current_state(TASK_RUNNING);
> > +	freezer_count();
> >   
> >   	try_to_freeze();
> >   
> 
> 
> Thanks. I gave this a try on top of v5.15.160-rc1, but I am still seeing
> the following and the board hangs ...
> 
> Freezing of tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
> 
> So unfortunately this does not fix it :-(

Thanks for testing.
I can only guess that you had an active NFSv4.1 mount and that the
callback thread was causing problems.  Please try this.  I also changed
to use freezable_schedule* which seems like a better interface to do the
same thing.

If this doesn't fix it, we'll probably need to ask someone who remembers
the old freezer code.

Thanks,
NeilBrown

From 518f0c1150f988b3fe8e5e0d053a25c3aa6c7d44 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.de>
Date: Wed, 29 May 2024 09:38:22 +1000
Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:

Prior to v6.1, the freezer will only wake a kernel thread from an
uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
ignore it instead.

To make this work with only upstream requests we would need
  Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
which allows non-interruptible sleeps to be woken by the freezer.

Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
Signed-off-by: NeilBrown <neilb@suse.de>
---
 fs/nfs/callback.c     | 2 +-
 fs/nfsd/nfs4proc.c    | 3 ++-
 net/sunrpc/svc_xprt.c | 4 ++--
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
index 46a0a2d6962e..8fe143cad4a2 100644
--- a/fs/nfs/callback.c
+++ b/fs/nfs/callback.c
@@ -124,7 +124,7 @@ nfs41_callback_svc(void *vrqstp)
 		} else {
 			spin_unlock_bh(&serv->sv_cb_lock);
 			if (!kthread_should_stop())
-				schedule();
+				freezable_schedule();
 			finish_wait(&serv->sv_cb_waitq, &wq);
 		}
 	}
diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
index 6779291efca9..e0ff2212866a 100644
--- a/fs/nfsd/nfs4proc.c
+++ b/fs/nfsd/nfs4proc.c
@@ -38,6 +38,7 @@
 #include <linux/slab.h>
 #include <linux/kthread.h>
 #include <linux/namei.h>
+#include <linux/freezer.h>
 
 #include <linux/sunrpc/addr.h>
 #include <linux/nfs_ssc.h>
@@ -1322,7 +1323,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr,
 
 			/* allow 20secs for mount/unmount for now - revisit */
 			if (kthread_should_stop() ||
-					(schedule_timeout(20*HZ) == 0)) {
+					(freezable_schedule_timeout(20*HZ) == 0)) {
 				finish_wait(&nn->nfsd_ssc_waitq, &wait);
 				kfree(work);
 				return nfserr_eagain;
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index b19592673eef..3cf53e3140a5 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -705,7 +705,7 @@ static int svc_alloc_arg(struct svc_rqst *rqstp)
 			set_current_state(TASK_RUNNING);
 			return -EINTR;
 		}
-		schedule_timeout(msecs_to_jiffies(500));
+		freezable_schedule_timeout(msecs_to_jiffies(500));
 	}
 	rqstp->rq_page_end = &rqstp->rq_pages[pages];
 	rqstp->rq_pages[pages] = NULL; /* this might be seen in nfsd_splice_actor() */
@@ -765,7 +765,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
 	smp_mb__after_atomic();
 
 	if (likely(rqst_should_sleep(rqstp)))
-		time_left = schedule_timeout(timeout);
+		time_left = freezable_schedule_timeout(timeout);
 	else
 		__set_current_state(TASK_RUNNING);
 
-- 
2.44.0

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Jon Hunter]

On 29/05/2024 21:59, NeilBrown wrote:

...

> Thanks for testing.
> I can only guess that you had an active NFSv4.1 mount and that the
> callback thread was causing problems.  Please try this.  I also changed
> to use freezable_schedule* which seems like a better interface to do the
> same thing.
> 
> If this doesn't fix it, we'll probably need to ask someone who remembers
> the old freezer code.
> 
> Thanks,
> NeilBrown
> 
>  From 518f0c1150f988b3fe8e5e0d053a25c3aa6c7d44 Mon Sep 17 00:00:00 2001
> From: NeilBrown <neilb@suse.de>
> Date: Wed, 29 May 2024 09:38:22 +1000
> Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
> 
> Prior to v6.1, the freezer will only wake a kernel thread from an
> uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
> IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
> ignore it instead.
> 
> To make this work with only upstream requests we would need
>    Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
> which allows non-interruptible sleeps to be woken by the freezer.
> 
> Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
>   fs/nfs/callback.c     | 2 +-
>   fs/nfsd/nfs4proc.c    | 3 ++-
>   net/sunrpc/svc_xprt.c | 4 ++--
>   3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
> index 46a0a2d6962e..8fe143cad4a2 100644
> --- a/fs/nfs/callback.c
> +++ b/fs/nfs/callback.c
> @@ -124,7 +124,7 @@ nfs41_callback_svc(void *vrqstp)
>   		} else {
>   			spin_unlock_bh(&serv->sv_cb_lock);
>   			if (!kthread_should_stop())
> -				schedule();
> +				freezable_schedule();
>   			finish_wait(&serv->sv_cb_waitq, &wq);
>   		}
>   	}
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index 6779291efca9..e0ff2212866a 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -38,6 +38,7 @@
>   #include <linux/slab.h>
>   #include <linux/kthread.h>
>   #include <linux/namei.h>
> +#include <linux/freezer.h>
>   
>   #include <linux/sunrpc/addr.h>
>   #include <linux/nfs_ssc.h>
> @@ -1322,7 +1323,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr,
>   
>   			/* allow 20secs for mount/unmount for now - revisit */
>   			if (kthread_should_stop() ||
> -					(schedule_timeout(20*HZ) == 0)) {
> +					(freezable_schedule_timeout(20*HZ) == 0)) {
>   				finish_wait(&nn->nfsd_ssc_waitq, &wait);
>   				kfree(work);
>   				return nfserr_eagain;
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index b19592673eef..3cf53e3140a5 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -705,7 +705,7 @@ static int svc_alloc_arg(struct svc_rqst *rqstp)
>   			set_current_state(TASK_RUNNING);
>   			return -EINTR;
>   		}
> -		schedule_timeout(msecs_to_jiffies(500));
> +		freezable_schedule_timeout(msecs_to_jiffies(500));
>   	}
>   	rqstp->rq_page_end = &rqstp->rq_pages[pages];
>   	rqstp->rq_pages[pages] = NULL; /* this might be seen in nfsd_splice_actor() */
> @@ -765,7 +765,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
>   	smp_mb__after_atomic();
>   
>   	if (likely(rqst_should_sleep(rqstp)))
> -		time_left = schedule_timeout(timeout);
> +		time_left = freezable_schedule_timeout(timeout);
>   	else
>   		__set_current_state(TASK_RUNNING);
>   


That did the trick! Suspend is now working again on top of v5.15.160-rc1 
with this change.

Feel free to add my ...

Tested-by: Jon Hunter <jonathanh@nvidia.com>

Thanks
Jon

-- 
nvpublic

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever III]

> On May 29, 2024, at 4:59 PM, NeilBrown <neilb@suse.de> wrote:
> 
> On Wed, 29 May 2024, Jon Hunter wrote:
>> On 29/05/2024 00:42, NeilBrown wrote:
>>> On Wed, 29 May 2024, NeilBrown wrote:
>>>> 
>>>> We probably just need to add "| TASK_FREEZABLE" in one or two places.
>>>> I'll post a patch for testing in a little while.
>>> 
>>> There is no TASK_FREEZABLE before v6.1.
>>> This isn't due to a missed backport. It is simply because of differences
>>> in the freezer in older kernels.
>>> 
>>> Please test this patch.
>>> 
>>> Thanks,
>>> NeilBrown
>>> 
>>> From 416bd6ae9a598e64931d34b76aa58f39b11841cd Mon Sep 17 00:00:00 2001
>>> From: NeilBrown <neilb@suse.de>
>>> Date: Wed, 29 May 2024 09:38:22 +1000
>>> Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
>>> 
>>> Prior to v6.1, the freezer will only wake a kernel thread from an
>>> uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
>>> IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
>>> ignore it instead.
>>> 
>>> Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
>>> Signed-off-by: NeilBrown <neilb@suse.de>
>>> ---
>>>  net/sunrpc/svc_xprt.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>> 
>>> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
>>> index b19592673eef..12e9293bd12b 100644
>>> --- a/net/sunrpc/svc_xprt.c
>>> +++ b/net/sunrpc/svc_xprt.c
>>> @@ -764,10 +764,12 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
>>>   clear_bit(RQ_BUSY, &rqstp->rq_flags);
>>>   smp_mb__after_atomic();
>>> 
>>> + freezer_do_not_count();
>>>   if (likely(rqst_should_sleep(rqstp)))
>>>   time_left = schedule_timeout(timeout);
>>>   else
>>>   __set_current_state(TASK_RUNNING);
>>> + freezer_count();
>>> 
>>>   try_to_freeze();
>>> 
>> 
>> 
>> Thanks. I gave this a try on top of v5.15.160-rc1, but I am still seeing
>> the following and the board hangs ...
>> 
>> Freezing of tasks failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>> 
>> So unfortunately this does not fix it :-(
> 
> Thanks for testing.
> I can only guess that you had an active NFSv4.1 mount and that the
> callback thread was causing problems.  Please try this.  I also changed
> to use freezable_schedule* which seems like a better interface to do the
> same thing.
> 
> If this doesn't fix it, we'll probably need to ask someone who remembers
> the old freezer code.
> 
> Thanks,
> NeilBrown
> 
> From 518f0c1150f988b3fe8e5e0d053a25c3aa6c7d44 Mon Sep 17 00:00:00 2001
> From: NeilBrown <neilb@suse.de>
> Date: Wed, 29 May 2024 09:38:22 +1000
> Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
> 
> Prior to v6.1, the freezer will only wake a kernel thread from an
> uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
> IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
> ignore it instead.
> 
> To make this work with only upstream requests we would need
>  Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
> which allows non-interruptible sleeps to be woken by the freezer.
> 
> Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
> Signed-off-by: NeilBrown <neilb@suse.de>
> ---
> fs/nfs/callback.c     | 2 +-
> fs/nfsd/nfs4proc.c    | 3 ++-
> net/sunrpc/svc_xprt.c | 4 ++--
> 3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
> index 46a0a2d6962e..8fe143cad4a2 100644
> --- a/fs/nfs/callback.c
> +++ b/fs/nfs/callback.c
> @@ -124,7 +124,7 @@ nfs41_callback_svc(void *vrqstp)
> } else {
> spin_unlock_bh(&serv->sv_cb_lock);
> if (!kthread_should_stop())
> - schedule();
> + freezable_schedule();
> finish_wait(&serv->sv_cb_waitq, &wq);
> }
> }
> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> index 6779291efca9..e0ff2212866a 100644
> --- a/fs/nfsd/nfs4proc.c
> +++ b/fs/nfsd/nfs4proc.c
> @@ -38,6 +38,7 @@
> #include <linux/slab.h>
> #include <linux/kthread.h>
> #include <linux/namei.h>
> +#include <linux/freezer.h>
> 
> #include <linux/sunrpc/addr.h>
> #include <linux/nfs_ssc.h>
> @@ -1322,7 +1323,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr,
> 
> /* allow 20secs for mount/unmount for now - revisit */
> if (kthread_should_stop() ||
> - (schedule_timeout(20*HZ) == 0)) {
> + (freezable_schedule_timeout(20*HZ) == 0)) {
> finish_wait(&nn->nfsd_ssc_waitq, &wait);
> kfree(work);
> return nfserr_eagain;
> diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> index b19592673eef..3cf53e3140a5 100644
> --- a/net/sunrpc/svc_xprt.c
> +++ b/net/sunrpc/svc_xprt.c
> @@ -705,7 +705,7 @@ static int svc_alloc_arg(struct svc_rqst *rqstp)
> set_current_state(TASK_RUNNING);
> return -EINTR;
> }
> - schedule_timeout(msecs_to_jiffies(500));
> + freezable_schedule_timeout(msecs_to_jiffies(500));
> }
> rqstp->rq_page_end = &rqstp->rq_pages[pages];
> rqstp->rq_pages[pages] = NULL; /* this might be seen in nfsd_splice_actor() */
> @@ -765,7 +765,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
> smp_mb__after_atomic();
> 
> if (likely(rqst_should_sleep(rqstp)))
> - time_left = schedule_timeout(timeout);
> + time_left = freezable_schedule_timeout(timeout);
> else
> __set_current_state(TASK_RUNNING);
> 
> -- 
> 2.44.0

I will merge this into nfsd-5.10.

I can also run this past NFSD's upstream CI and send it along to
stable if you would like.


--
Chuck Lever

Re: [PATCH 5.15 00/23] 5.15.160-rc1 review

[Chuck Lever]

On Thu, May 30, 2024 at 01:11:47PM +0100, Jon Hunter wrote:
> 
> On 29/05/2024 21:59, NeilBrown wrote:
> 
> ...
> 
> > Thanks for testing.
> > I can only guess that you had an active NFSv4.1 mount and that the
> > callback thread was causing problems.  Please try this.  I also changed
> > to use freezable_schedule* which seems like a better interface to do the
> > same thing.
> > 
> > If this doesn't fix it, we'll probably need to ask someone who remembers
> > the old freezer code.
> > 
> > Thanks,
> > NeilBrown
> > 
> >  From 518f0c1150f988b3fe8e5e0d053a25c3aa6c7d44 Mon Sep 17 00:00:00 2001
> > From: NeilBrown <neilb@suse.de>
> > Date: Wed, 29 May 2024 09:38:22 +1000
> > Subject: [PATCH] sunrpc: exclude from freezer when waiting for requests:
> > 
> > Prior to v6.1, the freezer will only wake a kernel thread from an
> > uninterruptible sleep.  Since we changed svc_get_next_xprt() to use and
> > IDLE sleep the freezer cannot wake it.  we need to tell the freezer to
> > ignore it instead.
> > 
> > To make this work with only upstream requests we would need
> >    Commit f5d39b020809 ("freezer,sched: Rewrite core freezer logic")
> > which allows non-interruptible sleeps to be woken by the freezer.
> > 
> > Fixes: 9b8a8e5e8129 ("nfsd: don't allow nfsd threads to be signalled.")
> > Signed-off-by: NeilBrown <neilb@suse.de>
> > ---
> >   fs/nfs/callback.c     | 2 +-
> >   fs/nfsd/nfs4proc.c    | 3 ++-
> >   net/sunrpc/svc_xprt.c | 4 ++--
> >   3 files changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
> > index 46a0a2d6962e..8fe143cad4a2 100644
> > --- a/fs/nfs/callback.c
> > +++ b/fs/nfs/callback.c
> > @@ -124,7 +124,7 @@ nfs41_callback_svc(void *vrqstp)
> >   		} else {
> >   			spin_unlock_bh(&serv->sv_cb_lock);
> >   			if (!kthread_should_stop())
> > -				schedule();
> > +				freezable_schedule();
> >   			finish_wait(&serv->sv_cb_waitq, &wq);
> >   		}
> >   	}
> > diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
> > index 6779291efca9..e0ff2212866a 100644
> > --- a/fs/nfsd/nfs4proc.c
> > +++ b/fs/nfsd/nfs4proc.c
> > @@ -38,6 +38,7 @@
> >   #include <linux/slab.h>
> >   #include <linux/kthread.h>
> >   #include <linux/namei.h>
> > +#include <linux/freezer.h>
> >   #include <linux/sunrpc/addr.h>
> >   #include <linux/nfs_ssc.h>
> > @@ -1322,7 +1323,7 @@ static __be32 nfsd4_ssc_setup_dul(struct nfsd_net *nn, char *ipaddr,
> >   			/* allow 20secs for mount/unmount for now - revisit */
> >   			if (kthread_should_stop() ||
> > -					(schedule_timeout(20*HZ) == 0)) {
> > +					(freezable_schedule_timeout(20*HZ) == 0)) {
> >   				finish_wait(&nn->nfsd_ssc_waitq, &wait);
> >   				kfree(work);
> >   				return nfserr_eagain;
> > diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
> > index b19592673eef..3cf53e3140a5 100644
> > --- a/net/sunrpc/svc_xprt.c
> > +++ b/net/sunrpc/svc_xprt.c
> > @@ -705,7 +705,7 @@ static int svc_alloc_arg(struct svc_rqst *rqstp)
> >   			set_current_state(TASK_RUNNING);
> >   			return -EINTR;
> >   		}
> > -		schedule_timeout(msecs_to_jiffies(500));
> > +		freezable_schedule_timeout(msecs_to_jiffies(500));
> >   	}
> >   	rqstp->rq_page_end = &rqstp->rq_pages[pages];
> >   	rqstp->rq_pages[pages] = NULL; /* this might be seen in nfsd_splice_actor() */
> > @@ -765,7 +765,7 @@ static struct svc_xprt *svc_get_next_xprt(struct svc_rqst *rqstp, long timeout)
> >   	smp_mb__after_atomic();
> >   	if (likely(rqst_should_sleep(rqstp)))
> > -		time_left = schedule_timeout(timeout);
> > +		time_left = freezable_schedule_timeout(timeout);
> >   	else
> >   		__set_current_state(TASK_RUNNING);
> 
> 
> That did the trick! Suspend is now working again on top of v5.15.160-rc1
> with this change.
> 
> Feel free to add my ...
> 
> Tested-by: Jon Hunter <jonathanh@nvidia.com>

Since I've heard no objections, I've added this to nfsd-5.15.y for
testing. I plan to send it along to stable@ when testing completes.

-- 
Chuck Lever