Den 2022-07-15 kl. 21:58, skrev Salvatore Bonaccorso:
I would be interested to either pinpoint the regressing commit
upstream beween 5.10.120 and 5.10.127 or conversely the fixing commit
beween 5.10.127 upstream and 5.10.130 where you are not able anymore
to reproduce the error. What I can say, I have already imported
5.10.130 for furture upload (cf.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/506).
Bisection for the regression proved too hard.
Bisection for the fix went better, I can get a crash with 5.10.128-00010
but not yet with 5.10.128-00011. This indicates that the fixing commit
was probably:
commit 6a0b9512a6aa7b7835d8138f5ffdcb4789c093d4
Author: Chuck Lever <chuck.le...@oracle.com>
Date: Thu Jun 30 16:48:18 2022 -0400
SUNRPC: Fix READ_PLUS crasher
which indeed seems to touch code involved in NFS service.
Consequently, the breaking commit was probably:
6c254bf3b637 ("SUNRPC: Fix the calculation of xdr->end in
xdr_get_next_encode_buffer()")
Bisection would be a new experience for me, even compiling the kernel seem
like ages ago ... (using Debian since 0.93R6).
Would the following help?
https://wiki.debian.org/DebianKernel/GitBisect
Do you need any more specifc help to get it rolling?
That was indeed helpful.
Regards,
Salvatore
Thanks
Arne
