forked from torvalds/linux
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-Wunused-but-set-variable in fs/btrfs/free-space-cache.c #1672
Labels
-Wunused-but-set-variable
[BUG] linux-next
This is an issue only seen in linux-next
[FIXED][LINUX] development cycle
This bug was only present and fixed in a -next or -rc cycle
Comments
nathanchance
added
[PATCH] Submitted
A patch has been submitted for review
[BUG] linux-next
This is an issue only seen in linux-next
-Wunused-but-set-variable
labels
Jul 22, 2022
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this issue
Jul 22, 2022
When CONFIG_LOCKDEP is unset, there is a warning about the mapping variable being unused: fs/btrfs/free-space-cache.c:929:24: warning: variable 'mapping' set but not used [-Wunused-but-set-variable] struct address_space *mapping; ^ 1 warning generated. lockdep_set_class() does not do anything with the first parameter to the macro when CONFIG_LOCKDEP is not set so just eliminate the mapping variable and use inode instead, which is always used in the function. Fixes: 22d85ab ("btrfs: Change the lockdep class of struct inode's invalidate_lock") Link: ClangBuiltLinux#1672 Signed-off-by: Nathan Chancellor <nathan@kernel.org>
nathanchance
added a commit
to nathanchance/WSL2-Linux-Kernel
that referenced
this issue
Jul 22, 2022
When CONFIG_LOCKDEP is unset, there is a warning about the mapping variable being unused: fs/btrfs/free-space-cache.c:929:24: warning: variable 'mapping' set but not used [-Wunused-but-set-variable] struct address_space *mapping; ^ 1 warning generated. lockdep_set_class() does not do anything with the first parameter to the macro when CONFIG_LOCKDEP is not set so just eliminate the mapping variable and use inode instead, which is always used in the function. Fixes: 22d85ab ("btrfs: Change the lockdep class of struct inode's invalidate_lock") Link: ClangBuiltLinux/linux#1672 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220722163854.1189931-1-nathan@kernel.org
nathanchance
added a commit
to nathanchance/WSL2-Linux-Kernel
that referenced
this issue
Jul 25, 2022
When CONFIG_LOCKDEP is unset, there is a warning about the mapping variable being unused: fs/btrfs/free-space-cache.c:929:24: warning: variable 'mapping' set but not used [-Wunused-but-set-variable] struct address_space *mapping; ^ 1 warning generated. lockdep_set_class() does not do anything with the first parameter to the macro when CONFIG_LOCKDEP is not set so just eliminate the mapping variable and use inode instead, which is always used in the function. Fixes: 22d85ab ("btrfs: Change the lockdep class of struct inode's invalidate_lock") Link: ClangBuiltLinux/linux#1672 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220722163854.1189931-1-nathan@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
sounds like this got picked up? |
Yes, my diff was squashed into the original change: https://git.kernel.org/kdave/c/87d1edac403607bab93021afc48b05c234b3028a |
nathanchance
added
[PATCH] Accepted
A submitted patch has been accepted upstream
and removed
[PATCH] Submitted
A patch has been submitted for review
labels
Jul 25, 2022
Now fixed in next-20220726. |
nathanchance
added
[FIXED][LINUX] development cycle
This bug was only present and fixed in a -next or -rc cycle
and removed
[PATCH] Accepted
A submitted patch has been accepted upstream
labels
Jul 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
-Wunused-but-set-variable
[BUG] linux-next
This is an issue only seen in linux-next
[FIXED][LINUX] development cycle
This bug was only present and fixed in a -next or -rc cycle
Patch submitted: https://lore.kernel.org/20220722163854.1189931-1-nathan@kernel.org/
The text was updated successfully, but these errors were encountered: