Commit 9fd4523
Al Viro
add locked_recursive_removal()
simple_recursive_removal() assumes that parent is not locked and
locks it when it finally gets to removing the victim itself.
Usually that's what we want, but there are places where the
parent is *already* locked and we need it to stay that way.
In those cases simple_recursive_removal() would, of course,
deadlock, so we have to play racy games with unlocking/relocking
the parent around the call or open-code the entire thing.
A better solution is to provide a variant that expects to
be called with the parent already locked by the caller.
Parent should be locked with I_MUTEX_PARENT, to avoid false
positives from lockdep.
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>1 parent 2a8061e commit 9fd4523
2 files changed
Lines changed: 23 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
605 | 605 | | |
606 | 606 | | |
607 | 607 | | |
608 | | - | |
609 | | - | |
| 608 | + | |
| 609 | + | |
| 610 | + | |
610 | 611 | | |
611 | 612 | | |
612 | 613 | | |
| |||
625 | 626 | | |
626 | 627 | | |
627 | 628 | | |
628 | | - | |
| 629 | + | |
| 630 | + | |
629 | 631 | | |
630 | 632 | | |
631 | 633 | | |
| |||
638 | 640 | | |
639 | 641 | | |
640 | 642 | | |
641 | | - | |
| 643 | + | |
| 644 | + | |
642 | 645 | | |
643 | 646 | | |
644 | 647 | | |
| |||
647 | 650 | | |
648 | 651 | | |
649 | 652 | | |
| 653 | + | |
| 654 | + | |
| 655 | + | |
| 656 | + | |
| 657 | + | |
| 658 | + | |
650 | 659 | | |
651 | 660 | | |
| 661 | + | |
| 662 | + | |
| 663 | + | |
| 664 | + | |
| 665 | + | |
| 666 | + | |
| 667 | + | |
| 668 | + | |
652 | 669 | | |
653 | 670 | | |
654 | 671 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
3595 | 3595 | | |
3596 | 3596 | | |
3597 | 3597 | | |
| 3598 | + | |
| 3599 | + | |
3598 | 3600 | | |
3599 | 3601 | | |
3600 | 3602 | | |
| |||
0 commit comments