[ Upstream commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 ]
In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup().
Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free.
Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.
The origin of a cherry-pick conflict is the (relevant) code block added in commit f66af88e3321 ("gfs2: Stop using gfs2_make_fs_ro for withdraw")
There are no references to gfs2_withdrawn() nor gfs2_destroy_threads() in gfs2_put_super(), so we can simply call gfs2_quota_cleanup() in a new else block as bdcb8aa434c6 achieves.
Else braces were used for consistency with the if block.
Sponsor: 21SoftWare LLC Signed-off-by: Clayton Casciato majortomtosourcecontrol@gmail.com --- diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c index 302d1e43d701..6107cd680176 100644 --- a/fs/gfs2/super.c +++ b/fs/gfs2/super.c @@ -591,6 +591,8 @@ static void gfs2_put_super(struct super_block *sb)
if (!sb_rdonly(sb)) { gfs2_make_fs_ro(sdp); + } else { + gfs2_quota_cleanup(sdp); } WARN_ON(gfs2_withdrawing(sdp));
On Fri, Jun 28, 2024 at 12:07:52PM -0600, Clayton Casciato wrote:
[ Upstream commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 ]
In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup().
Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free.
Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.
The origin of a cherry-pick conflict is the (relevant) code block added in commit f66af88e3321 ("gfs2: Stop using gfs2_make_fs_ro for withdraw")
There are no references to gfs2_withdrawn() nor gfs2_destroy_threads() in gfs2_put_super(), so we can simply call gfs2_quota_cleanup() in a new else block as bdcb8aa434c6 achieves.
Else braces were used for consistency with the if block.
Sponsor: 21SoftWare LLC
That's not a valid tag for kernel commits, sorry.
Signed-off-by: Clayton Casciato majortomtosourcecontrol@gmail.com
What happened to the original authorship information, and all of the other signed-off-by that were on the original commit? YOu can not just delete them, would you want someone doing that to a patch you contributed?
as-is, we can't take this, please fix up.
thanks,
greg k-h
On 6/29/24 2:10 AM, Greg KH wrote:
On Fri, Jun 28, 2024 at 12:07:52PM -0600, Clayton Casciato wrote:
[ Upstream commit bdcb8aa434c6d36b5c215d02a9ef07551be25a37 ]
In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup().
Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free.
Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again.
The origin of a cherry-pick conflict is the (relevant) code block added in commit f66af88e3321 ("gfs2: Stop using gfs2_make_fs_ro for withdraw")
There are no references to gfs2_withdrawn() nor gfs2_destroy_threads() in gfs2_put_super(), so we can simply call gfs2_quota_cleanup() in a new else block as bdcb8aa434c6 achieves.
Else braces were used for consistency with the if block.
Sponsor: 21SoftWare LLC
That's not a valid tag for kernel commits, sorry.
The documentation mentions "some people also put extra tags at the end. They’ll just be ignored for now [...]"
I don't imagine this would be appropriate on a line *after* the sign-off?
Signed-off-by: Clayton Casciato majortomtosourcecontrol@gmail.com
What happened to the original authorship information, and all of the other signed-off-by that were on the original commit? YOu can not just delete them, would you want someone doing that to a patch you contributed?
I didn't understand this and was concerned along the lines of "it is very impolite to change one submitter’s code and make him endorse your bugs"
as-is, we can't take this, please fix up.
I've submitted v2
thanks,
greg k-h
Thank you for the feedback!
Clayton Casciato
linux-stable-mirror@lists.linaro.org
-
Clayton Casciato -
Greg KH