Hi Greg,
For what it's worth, bisection points to 903b487b5ba6 ("udf: Handle error when adding extent to a file").
I see the following commit is fixing the reported problem.
commit 6d5ab7c2f7cf90877dab8f2bb06eb5ca8edc73ef Author: Tom Rix trix@redhat.com Date: Fri Dec 30 12:53:41 2022 -0500
udf: initialize newblock to 0 The clang build reports this error fs/udf/inode.c:805:6: error: variable 'newblock' is useduninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (*err < 0) ^~~~~~~~ newblock is never set before error handling jump. Initialize newblock to 0 and remove redundant settings.
Fixes: d8b39db5fab8 ("udf: Handle error when adding extent to a file") Reported-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20221230175341.1629734-1-trix@redhat.com>Wait, where is this commit? I don't see it in Linus's tree either, nor in linux-next. Where did you find it?
Can you find this commit id ?
Commit id: 23970a1c9475b305770fd37bebfec7a10f263787 subject: ("udf: initialize newblock to 0")
Yes, that is in 6.2. Where did the id you used above come from?
While looking around for the fix commit i found this on Linux next,
$ git log --oneline next-20221226..next-20230106 -- fs/udf/inode.c e86812bfac97e udf: Detect system inodes linked into directory hierarchy 453bc25de0a55 udf: Preserve link count of system files 6d5ab7c2f7cf9 udf: initialize newblock to 0
confused,
Sorry for the confusion.
greg k-h
- Naresh