On 2025/07/16 4:20, Viacheslav Dubeyko wrote:
> I don't think that it makes sense to add the function name here. I
> understand that you would like to be informative here. But, usually,
> HFS code doesn't show the the function name in error messages.
>
> By the way, why are you using pr_warn() but not pr_err()? Any
> particular reason to use namely pr_warn()?
Simply mimicked
pr_warn("filesystem was not cleanly unmounted, running fsck.hfs is recommended. mounting read-only.\n");
pr_warn("filesystem was not cleanly unmounted, running fsck.hfs is recommended. leaving read-only.\n");
messages. But stronger level (i.e. pr_err()) is OK for locations
which should not occur.
> We had BUG() here before and, potentially, we could use pr_warn() +
> dump_stack() to be really informative here.
Since printing a lot of messages causes stalls, I'd like to keep minimum.
Although fsck.hfs cannot fix all problems in the filesystem image used by the
reproducer ( https://syzkaller.appspot.com/text?tag=ReproC&x=111450f0580000 ),
updating this patch to suggest running fsck.hfs might be helpful.
** /dev/loop0
Executing fsck_hfs (version 540.1-Linux).
** Checking HFS volume.
Invalid extent entry
(3, 0)
** The volume could not be verified completely.
