Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Naresh Kamboju]

On Tue, 7 Jun 2022 at 23:41, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.17.14 release.
> There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.17.14-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.17.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.

Regressions found on qemu_x86_64:
  - kunit/kasan [1]

Regressions found on qemu_i386:
  - kunit/kfence [2]
  - kunit/test_out_of_bounds_read

We will bisect and let you know more details about this reported problem.

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

[1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/

## Build
* kernel: 5.17.14-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.17.y
* git commit: d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
* git describe: v5.17.13-773-gd0f9b2818e1e
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e

## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
Regressions found on qemu_x86_64:
  - kunit/kasan [1]

Regressions found on qemu_i386:
  - kunit/kfence [2]
  - kunit/test_out_of_bounds_read

## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
No metric regressions found.

## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
No test fixes found.

## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
No metric fixes found.

## Test result summary
total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859

## Build Summary
* arm: 17 total, 14 passed, 3 failed
* arm64: 20 total, 20 passed, 0 failed
* i386: 17 total, 12 passed, 5 failed
* mips: 4 total, 1 passed, 3 failed
* parisc: 2 total, 2 passed, 0 failed
* powerpc: 5 total, 2 passed, 3 failed
* riscv: 5 total, 5 passed, 0 failed
* s390: 5 total, 2 passed, 3 failed
* sh: 2 total, 0 passed, 2 failed
* sparc: 2 total, 2 passed, 0 failed
* x86_64: 20 total, 20 passed, 0 failed

## Test suites summary
* fwts
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-cap_bounds-tests
* ltp-commands
* ltp-commands-tests
* ltp-containers
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests
* ltp-fcntl-locktests-tests
* ltp-filecaps
* ltp-filecaps-tests
* ltp-fs
* ltp-fs-tests
* ltp-fs_bind
* ltp-fs_bind-tests
* ltp-fs_perms_simple
* ltp-fs_perms_simple-tests
* ltp-fsx
* ltp-fsx-tests
* ltp-hugetlb
* ltp-hugetlb-tests
* ltp-io
* ltp-io-tests
* ltp-ipc
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
* vdso

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

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Naresh Kamboju]

On Wed, 8 Jun 2022 at 19:24, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>
> On Tue, 7 Jun 2022 at 23:41, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > This is the start of the stable review cycle for the 5.17.14 release.
> > There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.17.14-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.17.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
>
> Regressions found on qemu_x86_64:
>   - kunit/kasan [1]
>
> Regressions found on qemu_i386:
>   - kunit/kfence [2]
>   - kunit/test_out_of_bounds_read
>
> We will bisect and let you know more details about this reported problem.

The bisect script pointed me to this commit and  reverted and tested and
confirmed.

commit 1883088ed4a0d5cc9cea500ca4e89a354ab32c11
Author: Jia-Ju Bai <baijiaju1990@gmail.com>
Date:   Fri May 27 23:28:18 2022 +0800

    md: bcache: check the return value of kzalloc() in detached_dev_do_request()

    commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.

    The function kzalloc() in detached_dev_do_request() can fail, so its
    return value should be checked.

    Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
bcache devices")
    Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
    Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
    Signed-off-by: Coly Li <colyli@suse.de>
    Link: https://lore.kernel.org/r/20220527152818.27545-4-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index d15aae6c51c1..673a680240a9 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
bcache_device *d, struct bio *bio,
         * which would call closure_get(&dc->disk.cl)
         */
        ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
+       if (!ddip) {
+               bio->bi_status = BLK_STS_RESOURCE;
+               bio->bi_end_io(bio);
+               return;
+       }
+
        ddip->d = d;
        /* Count on the bcache device */
        ddip->orig_bdev = orig_bdev;



> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>
> [1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
> [2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/
>
> ## Build
> * kernel: 5.17.14-rc1
> * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
> * git branch: linux-5.17.y
> * git commit: d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
> * git describe: v5.17.13-773-gd0f9b2818e1e
> * test details:
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e
>
> ## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
> Regressions found on qemu_x86_64:
>   - kunit/kasan [1]
>
> Regressions found on qemu_i386:
>   - kunit/kfence [2]
>   - kunit/test_out_of_bounds_read
>
> ## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
> No metric regressions found.
>
> ## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
> No test fixes found.
>
> ## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
> No metric fixes found.
>
> ## Test result summary
> total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859
>
> ## Build Summary
> * arm: 17 total, 14 passed, 3 failed
> * arm64: 20 total, 20 passed, 0 failed
> * i386: 17 total, 12 passed, 5 failed
> * mips: 4 total, 1 passed, 3 failed
> * parisc: 2 total, 2 passed, 0 failed
> * powerpc: 5 total, 2 passed, 3 failed
> * riscv: 5 total, 5 passed, 0 failed
> * s390: 5 total, 2 passed, 3 failed
> * sh: 2 total, 0 passed, 2 failed
> * sparc: 2 total, 2 passed, 0 failed
> * x86_64: 20 total, 20 passed, 0 failed
>
> ## Test suites summary
> * fwts
> * kunit
> * kvm-unit-tests
> * libgpiod
> * libhugetlbfs
> * log-parser-boot
> * log-parser-test
> * ltp-cap_bounds
> * ltp-cap_bounds-tests
> * ltp-commands
> * ltp-commands-tests
> * ltp-containers
> * ltp-containers-tests
> * ltp-controllers-tests
> * ltp-cpuhotplug-tests
> * ltp-crypto
> * ltp-crypto-tests
> * ltp-cve-tests
> * ltp-dio-tests
> * ltp-fcntl-locktests
> * ltp-fcntl-locktests-tests
> * ltp-filecaps
> * ltp-filecaps-tests
> * ltp-fs
> * ltp-fs-tests
> * ltp-fs_bind
> * ltp-fs_bind-tests
> * ltp-fs_perms_simple
> * ltp-fs_perms_simple-tests
> * ltp-fsx
> * ltp-fsx-tests
> * ltp-hugetlb
> * ltp-hugetlb-tests
> * ltp-io
> * ltp-io-tests
> * ltp-ipc
> * ltp-ipc-tests
> * ltp-math-tests
> * ltp-mm-tests
> * ltp-nptl
> * ltp-nptl-tests
> * ltp-open-posix-tests
> * ltp-pty
> * ltp-pty-tests
> * ltp-sched-tests
> * ltp-securebits
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * ltp-tracing-tests
> * network-basic-tests
> * packetdrill
> * perf
> * rcutorture
> * ssuite
> * v4l2-compliance
> * vdso
>
> --
> Linaro LKFT
> https://lkft.linaro.org

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Guenter Roeck]

On 6/9/22 05:51, Naresh Kamboju wrote:
> On Wed, 8 Jun 2022 at 19:24, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
>>
>> On Tue, 7 Jun 2022 at 23:41, Greg Kroah-Hartman
>> <gregkh@linuxfoundation.org> wrote:
>>>
>>> This is the start of the stable review cycle for the 5.17.14 release.
>>> There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.17.14-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.17.y
>>> and the diffstat can be found below.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> Results from Linaro’s test farm.
>>
>> Regressions found on qemu_x86_64:
>>    - kunit/kasan [1]
>>
>> Regressions found on qemu_i386:
>>    - kunit/kfence [2]
>>    - kunit/test_out_of_bounds_read
>>
>> We will bisect and let you know more details about this reported problem.
> 
> The bisect script pointed me to this commit and  reverted and tested and
> confirmed.
> 

I see the same error messages after enabling CONFIG_KFENCE_KUNIT_TEST, but
it doesn't go away after removing the patch below. That patch also seems
to be completely unrelated to the error.

I also see the same problem in the mainline kernel. I suspect that something
is wrong with CONFIG_KFENCE_KUNIT_TEST.

Guenter

> commit 1883088ed4a0d5cc9cea500ca4e89a354ab32c11
> Author: Jia-Ju Bai <baijiaju1990@gmail.com>
> Date:   Fri May 27 23:28:18 2022 +0800
> 
>      md: bcache: check the return value of kzalloc() in detached_dev_do_request()
> 
>      commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.
> 
>      The function kzalloc() in detached_dev_do_request() can fail, so its
>      return value should be checked.
> 
>      Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
> bcache devices")
>      Reported-by: TOTE Robot <oslab@tsinghua.edu.cn>
>      Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>      Signed-off-by: Coly Li <colyli@suse.de>
>      Link: https://lore.kernel.org/r/20220527152818.27545-4-colyli@suse.de
>      Signed-off-by: Jens Axboe <axboe@kernel.dk>
>      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
> index d15aae6c51c1..673a680240a9 100644
> --- a/drivers/md/bcache/request.c
> +++ b/drivers/md/bcache/request.c
> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
> bcache_device *d, struct bio *bio,
>           * which would call closure_get(&dc->disk.cl)
>           */
>          ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
> +       if (!ddip) {
> +               bio->bi_status = BLK_STS_RESOURCE;
> +               bio->bi_end_io(bio);
> +               return;
> +       }
> +
>          ddip->d = d;
>          /* Count on the bcache device */
>          ddip->orig_bdev = orig_bdev;
> 
> 
> 
>> Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
>>
>> [1] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038101/suite/kunit/test/kasan/details/
>> [2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e/testrun/10038215/suite/kunit/test/kfence/details/
>>
>> ## Build
>> * kernel: 5.17.14-rc1
>> * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
>> * git branch: linux-5.17.y
>> * git commit: d0f9b2818e1e4d43847e10d6e5310a0c653cb18f
>> * git describe: v5.17.13-773-gd0f9b2818e1e
>> * test details:
>> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17.13-773-gd0f9b2818e1e
>>
>> ## Test Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
>> Regressions found on qemu_x86_64:
>>    - kunit/kasan [1]
>>
>> Regressions found on qemu_i386:
>>    - kunit/kfence [2]
>>    - kunit/test_out_of_bounds_read
>>
>> ## Metric Regressions (compared to v5.17.11-188-g8eb69e8f0d45)
>> No metric regressions found.
>>
>> ## Test Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
>> No test fixes found.
>>
>> ## Metric Fixes (compared to v5.17.11-188-g8eb69e8f0d45)
>> No metric fixes found.
>>
>> ## Test result summary
>> total: 134591, pass: 121555, fail: 447, skip: 11730, xfail: 859
>>
>> ## Build Summary
>> * arm: 17 total, 14 passed, 3 failed
>> * arm64: 20 total, 20 passed, 0 failed
>> * i386: 17 total, 12 passed, 5 failed
>> * mips: 4 total, 1 passed, 3 failed
>> * parisc: 2 total, 2 passed, 0 failed
>> * powerpc: 5 total, 2 passed, 3 failed
>> * riscv: 5 total, 5 passed, 0 failed
>> * s390: 5 total, 2 passed, 3 failed
>> * sh: 2 total, 0 passed, 2 failed
>> * sparc: 2 total, 2 passed, 0 failed
>> * x86_64: 20 total, 20 passed, 0 failed
>>
>> ## Test suites summary
>> * fwts
>> * kunit
>> * kvm-unit-tests
>> * libgpiod
>> * libhugetlbfs
>> * log-parser-boot
>> * log-parser-test
>> * ltp-cap_bounds
>> * ltp-cap_bounds-tests
>> * ltp-commands
>> * ltp-commands-tests
>> * ltp-containers
>> * ltp-containers-tests
>> * ltp-controllers-tests
>> * ltp-cpuhotplug-tests
>> * ltp-crypto
>> * ltp-crypto-tests
>> * ltp-cve-tests
>> * ltp-dio-tests
>> * ltp-fcntl-locktests
>> * ltp-fcntl-locktests-tests
>> * ltp-filecaps
>> * ltp-filecaps-tests
>> * ltp-fs
>> * ltp-fs-tests
>> * ltp-fs_bind
>> * ltp-fs_bind-tests
>> * ltp-fs_perms_simple
>> * ltp-fs_perms_simple-tests
>> * ltp-fsx
>> * ltp-fsx-tests
>> * ltp-hugetlb
>> * ltp-hugetlb-tests
>> * ltp-io
>> * ltp-io-tests
>> * ltp-ipc
>> * ltp-ipc-tests
>> * ltp-math-tests
>> * ltp-mm-tests
>> * ltp-nptl
>> * ltp-nptl-tests
>> * ltp-open-posix-tests
>> * ltp-pty
>> * ltp-pty-tests
>> * ltp-sched-tests
>> * ltp-securebits
>> * ltp-securebits-tests
>> * ltp-syscalls-tests
>> * ltp-tracing-tests
>> * network-basic-tests
>> * packetdrill
>> * perf
>> * rcutorture
>> * ssuite
>> * v4l2-compliance
>> * vdso
>>
>> --
>> Linaro LKFT
>> https://lkft.linaro.org

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Pavel Machek]

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

Hi!
> > >
> > > This is the start of the stable review cycle for the 5.17.14 release.
> > > There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.17.14-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.17.y
> > > and the diffstat can be found below.
> > >
...
> > We will bisect and let you know more details about this reported problem.
> 
> The bisect script pointed me to this commit and  reverted and tested and
> confirmed.

Can you add some printks into that? Because I'm pretty sure this patch
does not break anything. (It should not fix much, either.)

> commit 1883088ed4a0d5cc9cea500ca4e89a354ab32c11
> Author: Jia-Ju Bai <baijiaju1990@gmail.com>

>     md: bcache: check the return value of kzalloc() in detached_dev_do_request()
> 
>     commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.
> 
>     The function kzalloc() in detached_dev_do_request() can fail, so its
>     return value should be checked.
> 
>     Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
...

> +++ b/drivers/md/bcache/request.c
> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
> bcache_device *d, struct bio *bio,
>          * which would call closure_get(&dc->disk.cl)
>          */
>         ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
> +       if (!ddip) {
> +               bio->bi_status = BLK_STS_RESOURCE;
> +               bio->bi_end_io(bio);
> +               return;
> +       }
> +
>         ddip->d = d;
>         /* Count on the bcache device */
>         ddip->orig_bdev = orig_bdev;
> 

So... for patch to make any difference, memory allocation has to fail
and ddip has to be NULL.

Before the patch, it would oops in "ddip->d = d;". With the patch, you
do some kind of error handling. Even if it is buggy, it should not do
more harm than immediate oops.

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

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

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Coly Li]

> 2022年6月18日 18:49，Pavel Machek <pavel@denx.de> 写道：
> 
> Hi!
>>>> 
>>>> This is the start of the stable review cycle for the 5.17.14 release.
>>>> There are 772 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 Thu, 09 Jun 2022 16:48:02 +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.17.14-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.17.y
>>>> and the diffstat can be found below.
>>>> 
> ...
>>> We will bisect and let you know more details about this reported problem.
>> 
>> The bisect script pointed me to this commit and  reverted and tested and
>> confirmed.
> 
> Can you add some printks into that? Because I'm pretty sure this patch
> does not break anything. (It should not fix much, either.)
> 
>> commit 1883088ed4a0d5cc9cea500ca4e89a354ab32c11
>> Author: Jia-Ju Bai <baijiaju1990@gmail.com>
> 
>>    md: bcache: check the return value of kzalloc() in detached_dev_do_request()
>> 
>>    commit 40f567bbb3b0639d2ec7d1c6ad4b1b018f80cf19 upstream.
>> 
>>    The function kzalloc() in detached_dev_do_request() can fail, so its
>>    return value should be checked.
>> 
>>    Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
> ...
> 
>> +++ b/drivers/md/bcache/request.c
>> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
>> bcache_device *d, struct bio *bio,
>>         * which would call closure_get(&dc->disk.cl)
>>         */
>>        ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
>> +       if (!ddip) {
>> +               bio->bi_status = BLK_STS_RESOURCE;
>> +               bio->bi_end_io(bio);
>> +               return;
>> +       }
>> +
>>        ddip->d = d;
>>        /* Count on the bcache device */
>>        ddip->orig_bdev = orig_bdev;
>> 
> 
> So... for patch to make any difference, memory allocation has to fail
> and ddip has to be NULL.
> 
> Before the patch, it would oops in "ddip->d = d;". With the patch, you
> do some kind of error handling. Even if it is buggy, it should not do
> more harm than immediate oops.

I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?

BTW, maybe commit 7d6b902ea0e0 (“bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”) is necessary, how about trying to add it in?

Coly Li

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Pavel Machek]

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

Hi!

> >>    Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
> > ...
> > 
> >> +++ b/drivers/md/bcache/request.c
> >> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
> >> bcache_device *d, struct bio *bio,
> >>         * which would call closure_get(&dc->disk.cl)
> >>         */
> >>        ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
> >> +       if (!ddip) {
> >> +               bio->bi_status = BLK_STS_RESOURCE;
> >> +               bio->bi_end_io(bio);
> >> +               return;
> >> +       }
> >> +
> >>        ddip->d = d;
> >>        /* Count on the bcache device */
> >>        ddip->orig_bdev = orig_bdev;
> >> 
> > 
> > So... for patch to make any difference, memory allocation has to fail
> > and ddip has to be NULL.
> > 
> > Before the patch, it would oops in "ddip->d = d;". With the patch, you
> > do some kind of error handling. Even if it is buggy, it should not do
> > more harm than immediate oops.
> 
> I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
> 

Discussion happened on stable@vger.kernel.org mailing lists, archives
should be easily available. Copy went to lkml, too.

Best regards,
								Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.

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

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Coly Li]

> 2022年6月18日 19:37，Pavel Machek <pavel@ucw.cz> 写道：
> 
> Hi!
> 
>>>>   Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
>>> ...
>>> 
>>>> +++ b/drivers/md/bcache/request.c
>>>> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
>>>> bcache_device *d, struct bio *bio,
>>>>        * which would call closure_get(&dc->disk.cl)
>>>>        */
>>>>       ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
>>>> +       if (!ddip) {
>>>> +               bio->bi_status = BLK_STS_RESOURCE;
>>>> +               bio->bi_end_io(bio);
>>>> +               return;
>>>> +       }
>>>> +
>>>>       ddip->d = d;
>>>>       /* Count on the bcache device */
>>>>       ddip->orig_bdev = orig_bdev;
>>>> 
>>> 
>>> So... for patch to make any difference, memory allocation has to fail
>>> and ddip has to be NULL.
>>> 
>>> Before the patch, it would oops in "ddip->d = d;". With the patch, you
>>> do some kind of error handling. Even if it is buggy, it should not do
>>> more harm than immediate oops.
>> 
>> I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
>> 
> 
> Discussion happened on stable@vger.kernel.org mailing lists, archives
> should be easily available. Copy went to lkml, too.

Hi Pavel and Greg,

Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
- commit 7d6b902ea0e0 ("bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”)

I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.

Thanks.

Coly Li

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Greg Kroah-Hartman]

On Sat, Jun 18, 2022 at 07:57:01PM +0800, Coly Li wrote:
> 
> 
> > 2022年6月18日 19:37，Pavel Machek <pavel@ucw.cz> 写道：
> > 
> > Hi!
> > 
> >>>>   Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
> >>> ...
> >>> 
> >>>> +++ b/drivers/md/bcache/request.c
> >>>> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
> >>>> bcache_device *d, struct bio *bio,
> >>>>        * which would call closure_get(&dc->disk.cl)
> >>>>        */
> >>>>       ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
> >>>> +       if (!ddip) {
> >>>> +               bio->bi_status = BLK_STS_RESOURCE;
> >>>> +               bio->bi_end_io(bio);
> >>>> +               return;
> >>>> +       }
> >>>> +
> >>>>       ddip->d = d;
> >>>>       /* Count on the bcache device */
> >>>>       ddip->orig_bdev = orig_bdev;
> >>>> 
> >>> 
> >>> So... for patch to make any difference, memory allocation has to fail
> >>> and ddip has to be NULL.
> >>> 
> >>> Before the patch, it would oops in "ddip->d = d;". With the patch, you
> >>> do some kind of error handling. Even if it is buggy, it should not do
> >>> more harm than immediate oops.
> >> 
> >> I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
> >> 
> > 
> > Discussion happened on stable@vger.kernel.org mailing lists, archives
> > should be easily available. Copy went to lkml, too.
> 
> Hi Pavel and Greg,
> 
> Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
> - commit 7d6b902ea0e0 ("bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”)
> 
> I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.

Added where?

confused,

greg k-h

Re: [PATCH 5.17 000/772] 5.17.14-rc1 review

[Coly Li]

> 2022年6月20日 18:10，Greg Kroah-Hartman <gregkh@linuxfoundation.org> 写道：
> 
> On Sat, Jun 18, 2022 at 07:57:01PM +0800, Coly Li wrote:
>> 
>> 
>>> 2022年6月18日 19:37，Pavel Machek <pavel@ucw.cz> 写道：
>>> 
>>> Hi!
>>> 
>>>>>>  Fixes: bc082a55d25c ("bcache: fix inaccurate io state for detached
>>>>> ...
>>>>> 
>>>>>> +++ b/drivers/md/bcache/request.c
>>>>>> @@ -1107,6 +1107,12 @@ static void detached_dev_do_request(struct
>>>>>> bcache_device *d, struct bio *bio,
>>>>>>       * which would call closure_get(&dc->disk.cl)
>>>>>>       */
>>>>>>      ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
>>>>>> +       if (!ddip) {
>>>>>> +               bio->bi_status = BLK_STS_RESOURCE;
>>>>>> +               bio->bi_end_io(bio);
>>>>>> +               return;
>>>>>> +       }
>>>>>> +
>>>>>>      ddip->d = d;
>>>>>>      /* Count on the bcache device */
>>>>>>      ddip->orig_bdev = orig_bdev;
>>>>>> 
>>>>> 
>>>>> So... for patch to make any difference, memory allocation has to fail
>>>>> and ddip has to be NULL.
>>>>> 
>>>>> Before the patch, it would oops in "ddip->d = d;". With the patch, you
>>>>> do some kind of error handling. Even if it is buggy, it should not do
>>>>> more harm than immediate oops.
>>>> 
>>>> I just receive this single email and don’t have any idea for the context and what the problem is. Where can I see the whole conversation?
>>>> 
>>> 
>>> Discussion happened on stable@vger.kernel.org mailing lists, archives
>>> should be easily available. Copy went to lkml, too.
>> 
>> Hi Pavel and Greg,
>> 
>> Thanks for the hint, I see the context. I cannot tell the direct reason of the kfence regression, but it is worthy to have this patch in,
>> - commit 7d6b902ea0e0 ("bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()”)
>> 
>> I am not sure whether it is directly related to the kfence issue, it corrects potential unexpected stack state in some condition. Hope it may help a bit.
> 
> Added where?
> 
> confused,

I will post the patch to stable list for specific version. Thanks.

Coly Li