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@xxxxxxxxx> > > 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