| Message ID | 20210604013159.3126180-2-guro@fb.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | cgroup, blkcg: prevent dirty inodes to pin dying memory cgroups | expand |
On Thu 03-06-21 18:31:54, Roman Gushchin wrote: > If an inode's state has I_WILL_FREE flag set, the inode will be > freed soon, so there is no point in trying to switch the inode > to a different cgwb. > > I_WILL_FREE was ignored since the introduction of the inode switching, > so it looks like it doesn't lead to any noticeable issues for a user. > This is why the patch is not intended for a stable backport. > > Suggested-by: Jan Kara <jack@suse.cz> > Signed-off-by: Roman Gushchin <guro@fb.com> Looks good. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Honza > --- > fs/fs-writeback.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index e91980f49388..bd99890599e0 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -389,10 +389,10 @@ static void inode_switch_wbs_work_fn(struct work_struct *work) > xa_lock_irq(&mapping->i_pages); > > /* > - * Once I_FREEING is visible under i_lock, the eviction path owns > - * the inode and we shouldn't modify ->i_io_list. > + * Once I_FREEING or I_WILL_FREE are visible under i_lock, the eviction > + * path owns the inode and we shouldn't modify ->i_io_list. > */ > - if (unlikely(inode->i_state & I_FREEING)) > + if (unlikely(inode->i_state & (I_FREEING | I_WILL_FREE))) > goto skip_switch; > > trace_inode_switch_wbs(inode, old_wb, new_wb); > @@ -517,7 +517,7 @@ static void inode_switch_wbs(struct inode *inode, int new_wb_id) > /* while holding I_WB_SWITCH, no one else can update the association */ > spin_lock(&inode->i_lock); > if (!(inode->i_sb->s_flags & SB_ACTIVE) || > - inode->i_state & (I_WB_SWITCH | I_FREEING) || > + inode->i_state & (I_WB_SWITCH | I_FREEING | I_WILL_FREE) || > inode_to_wb(inode) == isw->new_wb) { > spin_unlock(&inode->i_lock); > goto out_free; > -- > 2.31.1 >
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index e91980f49388..bd99890599e0 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -389,10 +389,10 @@ static void inode_switch_wbs_work_fn(struct work_struct *work) xa_lock_irq(&mapping->i_pages); /* - * Once I_FREEING is visible under i_lock, the eviction path owns - * the inode and we shouldn't modify ->i_io_list. + * Once I_FREEING or I_WILL_FREE are visible under i_lock, the eviction + * path owns the inode and we shouldn't modify ->i_io_list. */ - if (unlikely(inode->i_state & I_FREEING)) + if (unlikely(inode->i_state & (I_FREEING | I_WILL_FREE))) goto skip_switch; trace_inode_switch_wbs(inode, old_wb, new_wb); @@ -517,7 +517,7 @@ static void inode_switch_wbs(struct inode *inode, int new_wb_id) /* while holding I_WB_SWITCH, no one else can update the association */ spin_lock(&inode->i_lock); if (!(inode->i_sb->s_flags & SB_ACTIVE) || - inode->i_state & (I_WB_SWITCH | I_FREEING) || + inode->i_state & (I_WB_SWITCH | I_FREEING | I_WILL_FREE) || inode_to_wb(inode) == isw->new_wb) { spin_unlock(&inode->i_lock); goto out_free;
If an inode's state has I_WILL_FREE flag set, the inode will be freed soon, so there is no point in trying to switch the inode to a different cgwb. I_WILL_FREE was ignored since the introduction of the inode switching, so it looks like it doesn't lead to any noticeable issues for a user. This is why the patch is not intended for a stable backport. Suggested-by: Jan Kara <jack@suse.cz> Signed-off-by: Roman Gushchin <guro@fb.com> --- fs/fs-writeback.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)