Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.35, v6.6.34, v6.6.33, v6.6.32, v6.6.31, v6.6.30, v6.6.29, v6.6.28, v6.6.27, v6.6.26 |
|
#
0636b34b |
| 09-Apr-2024 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM w
gfs2: Fix potential glock use-after-free on unmount
[ Upstream commit d98779e687726d8f8860f1c54b5687eec5f63a73 ]
When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.
Fixes: fb6791d100d1b ("GFS2: skip dlm_unlock calls in unmount") Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Cc: David Teigland <teigland@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7 |
|
#
d312fbf6 |
| 09-Oct-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern'
gfs2: No longer use 'extern' in function declarations
[ Upstream commit 0b2355fe91ac3756a9e29c8b833ba33f9affb520 ]
For non-static function declarations, external linkage is implied and the 'extern' keyword isn't needed. Some static checkers complain about the overuse of 'extern', so clean up all the function declarations.
In addition, remove 'extern' from the definition of free_local_statfs_inodes(); it isn't needed there, either.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: d98779e68772 ("gfs2: Fix potential glock use-after-free on unmount") Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45 |
|
#
0b93bac2 |
| 08-Aug-2023 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Remove LM_FLAG_PRIORITY flag
The last user of this flag was removed in commit b77b4a4815a9 ("gfs2: Rework freeze / thaw logic").
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
|
Revision tags: v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15 |
|
#
f0e56edc |
| 20-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Split the two kinds of glock "delete" work
Function delete_work_func() is used for two purposes:
* to immediately try to evict the glock's inode, and
* to verify after a little while that
gfs2: Split the two kinds of glock "delete" work
Function delete_work_func() is used for two purposes:
* to immediately try to evict the glock's inode, and
* to verify after a little while that the inode has been deleted as expected, and didn't just get skipped.
These two operations are not separated very well, so introduce two new glock flags to improved that. Split gfs2_queue_delete_work() into gfs2_queue_try_to_evict and gfs2_queue_verify_evict().
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
Revision tags: v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
0247f4e9 |
| 06-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Move delete workqueue into super block
Move the global delete workqueue into struct gfs2_sbd so that we can flush / drain it without interfering with other filesystems.
Signed-off-by: Andreas
gfs2: Move delete workqueue into super block
Move the global delete workqueue into struct gfs2_sbd so that we can flush / drain it without interfering with other filesystems.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
#
3056dc46 |
| 09-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Get rid of GLF_PENDING_DELETE flag
Get rid of the GLF_PENDING_DELETE glock flag introduced by commit a0e3cc65fa29 ("gfs2: Turn gl_delete into a delayed work"). The only use of that flag is to
gfs2: Get rid of GLF_PENDING_DELETE flag
Get rid of the GLF_PENDING_DELETE glock flag introduced by commit a0e3cc65fa29 ("gfs2: Turn gl_delete into a delayed work"). The only use of that flag is to prevent the iopen glock from being demoted (i.e., unlocked) while delete work is pending. It turns out that demoting the iopen glock while delete work is pending is perfectly fine; we only need to make sure that the glock isn't being freed while still in use. This is ensured by the previous patch because delete_work_func() owns a reference while the work is queued or running.
With these changes, gfs2_queue_delete_work() no longer takes the glock spin lock, so we can use it in iopen_go_callback() instead of open-coding it there.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
#
ba3e77a4 |
| 09-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Remove support for glock holder auto-demotion
Remove the support for glock holder auto-demotion (commit dc732906c245 and folow-ups) as we are not planning to use this feature, and the addition
gfs2: Remove support for glock holder auto-demotion
Remove the support for glock holder auto-demotion (commit dc732906c245 and folow-ups) as we are not planning to use this feature, and the additional code therefore only adds unnecessary complexity.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
#
3781ec9e |
| 05-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Uninline and improve glock_{set,clear}_object
Those functions have reached a size at which having them inline isn't useful anymore, so uninline them. In addition, report the glock name on ass
gfs2: Uninline and improve glock_{set,clear}_object
Those functions have reached a size at which having them inline isn't useful anymore, so uninline them. In addition, report the glock name on assertion failures.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
#
764665c6 |
| 03-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Clean up after gfs2_create_inode rework
Since commit 3d36e57ff768 ("gfs2: gfs2_create_inode rework"), gfs2_evict_inode() and gfs2_create_inode() / gfs2_inode_lookup() will synchronize via the
gfs2: Clean up after gfs2_create_inode rework
Since commit 3d36e57ff768 ("gfs2: gfs2_create_inode rework"), gfs2_evict_inode() and gfs2_create_inode() / gfs2_inode_lookup() will synchronize via the inode hash table and we can be certain that once a new inode is inserted into the inode hash table(), gfs2_evict_inode() has completely destroyed any previous versions. We no longer need to worry about overlapping inode object lifespans. Update the code and comments accordingly.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
#
4ad02083 |
| 02-Dec-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Make gfs2_glock_hold return its glock argument
This allows code like 'gl = gfs2_glock_hold(...)'.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62 |
|
#
053640a7 |
| 18-Aug-2022 |
Bob Peterson <rpeterso@redhat.com> |
gfs2: Dequeue waiters when withdrawn
When a withdraw occurs, ordinary (not system) glocks may not be granted anymore. Later, when the file system is unmounted, gfs2_gl_hash_clear() tries to clear ou
gfs2: Dequeue waiters when withdrawn
When a withdraw occurs, ordinary (not system) glocks may not be granted anymore. Later, when the file system is unmounted, gfs2_gl_hash_clear() tries to clear out all the glocks, but these un-grantable pending waiters prevent some glocks from being freed. So the unmount hangs, at least for its ten-minute timeout period.
This patch takes measures to remove any pending waiters from the glocks that will never be granted. This allows the unmount to proceed in a reasonable period of time.
Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|
Revision tags: v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45 |
|
#
de3f906f |
| 02-Jun-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Revert 'Fix "truncate in progress" hang'
Now that interrupted truncates are completed in the context of the process taking the glock, there is no need for the glock state engine to delegate th
gfs2: Revert 'Fix "truncate in progress" hang'
Now that interrupted truncates are completed in the context of the process taking the glock, there is no need for the glock state engine to delegate that task to gfs2_quotad or for quotad to perform those truncates anymore. Get rid of the obsolete associated infrastructure.
Reverts commit 813e0c46c9e2 ("GFS2: Fix "truncate in progress" hang").
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
show more ...
|
#
53d69132 |
| 10-Jun-2022 |
Andreas Gruenbacher <agruenba@redhat.com> |
gfs2: Instantiate glocks ouside of glock state engine
Instantiate glocks outside of the glock state engine: there is no real reason for instantiating them inside the glock state engine; it only comp
gfs2: Instantiate glocks ouside of glock state engine
Instantiate glocks outside of the glock state engine: there is no real reason for instantiating them inside the glock state engine; it only complicates the code.
Instead, instantiate them in gfs2_glock_wait() and gfs2_glock_async_wait() using the new gfs2_glock_holder_ready() helper. On top of that, the only other place that acquires a glock without using gfs2_glock_wait() or gfs2_glock_async_wait() is gfs2_upgrade_iopen_glock(), so call gfs2_glock_holder_ready() there as well.
If a dinode has a pending truncate, the glock-specific instantiate function for inodes wakes up the truncate function in the quota daemon. Waiting for the completion of the truncate was previously done by the glock state engine, but we now need to wait in inode_go_instantiate().
This also means that gfs2_instantiate() will now no longer return any "special" error codes.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
show more ...
|