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... 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.... [2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.17.y/build/v5.17....

## 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....

## 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

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... 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

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

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