Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH] writeback: clear auto_free in initializaiton
@ 2020-08-18 14:13 trix
2020-08-26 16:11 ` Jan Kara
0 siblings, 1 reply; 3+ messages in thread
From: trix @ 2020-08-18 14:13 UTC (permalink / raw)
To: viro; +Cc: linux-fsdevel, linux-kernel, Tom Rix
From: Tom Rix <trix@redhat.com>
Review fs/fs-writeback.c bdi_split_work_to_wbs
The CONFIG_CGROUP_WRITEBACK version contains this line
base_work->auto_free = 0;
Which seems like a strange place to set auto_free as
it is not where the rest of base_work is initialized.
In the default version of bdi_split_work_to_wbs, if a
successful malloc happens, base_work is copied and
auto_free is set to 1, else the base_work is
copied to another local valarible and its auto_free
is set to 0.
So move the clearing of auto_free to the
initialization of the local base_work structures.
Signed-off-by: Tom Rix <trix@redhat.com>
---
fs/fs-writeback.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index a605c3dddabc..fa1106de2ab0 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -881,7 +881,6 @@ static void bdi_split_work_to_wbs(struct backing_dev_info *bdi,
work = &fallback_work;
*work = *base_work;
work->nr_pages = nr_pages;
- work->auto_free = 0;
work->done = &fallback_work_done;
wb_queue_work(wb, work);
@@ -1055,10 +1054,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info *bdi,
{
might_sleep();
- if (!skip_if_busy || !writeback_in_progress(&bdi->wb)) {
- base_work->auto_free = 0;
+ if (!skip_if_busy || !writeback_in_progress(&bdi->wb))
wb_queue_work(&bdi->wb, base_work);
- }
}
#endif /* CONFIG_CGROUP_WRITEBACK */
@@ -2459,6 +2456,7 @@ static void __writeback_inodes_sb_nr(struct super_block *sb, unsigned long nr,
.done = &done,
.nr_pages = nr,
.reason = reason,
+ .auto_free = 0,
};
if (!bdi_has_dirty_io(bdi) || bdi == &noop_backing_dev_info)
@@ -2538,6 +2536,7 @@ void sync_inodes_sb(struct super_block *sb)
.done = &done,
.reason = WB_REASON_SYNC,
.for_sync = 1,
+ .auto_free = 0,
};
/*
--
2.18.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] writeback: clear auto_free in initializaiton
2020-08-18 14:13 [PATCH] writeback: clear auto_free in initializaiton trix
@ 2020-08-26 16:11 ` Jan Kara
2020-09-02 14:49 ` Tejun Heo
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kara @ 2020-08-26 16:11 UTC (permalink / raw)
To: trix; +Cc: viro, linux-fsdevel, linux-kernel, Tejun Heo
On Tue 18-08-20 07:13:30, trix@redhat.com wrote:
> From: Tom Rix <trix@redhat.com>
>
> Review fs/fs-writeback.c bdi_split_work_to_wbs
> The CONFIG_CGROUP_WRITEBACK version contains this line
> base_work->auto_free = 0;
It is actually the !CONFIG_CGROUP_WRITEBACK version...
> Which seems like a strange place to set auto_free as
> it is not where the rest of base_work is initialized.
Otherwise I agree it's a strange place. I've added Tejun to CC just in case
he remembers why he's added that.
> In the default version of bdi_split_work_to_wbs, if a
> successful malloc happens, base_work is copied and
> auto_free is set to 1, else the base_work is
> copied to another local valarible and its auto_free
> is set to 0.
>
> So move the clearing of auto_free to the
> initialization of the local base_work structures.
>
> Signed-off-by: Tom Rix <trix@redhat.com>
Some more comments below.
> ---
> fs/fs-writeback.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index a605c3dddabc..fa1106de2ab0 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -881,7 +881,6 @@ static void bdi_split_work_to_wbs(struct backing_dev_info *bdi,
> work = &fallback_work;
> *work = *base_work;
> work->nr_pages = nr_pages;
> - work->auto_free = 0;
> work->done = &fallback_work_done;
Honestly, I'd leave this alone. Although base_work should have auto_free ==
0, this assignment IMO helps readability.
> @@ -1055,10 +1054,8 @@ static void bdi_split_work_to_wbs(struct backing_dev_info *bdi,
> {
> might_sleep();
>
> - if (!skip_if_busy || !writeback_in_progress(&bdi->wb)) {
> - base_work->auto_free = 0;
> + if (!skip_if_busy || !writeback_in_progress(&bdi->wb))
> wb_queue_work(&bdi->wb, base_work);
> - }
Agreed with this.
> @@ -2459,6 +2456,7 @@ static void __writeback_inodes_sb_nr(struct super_block *sb, unsigned long nr,
> .done = &done,
> .nr_pages = nr,
> .reason = reason,
> + .auto_free = 0,
> };
>
> if (!bdi_has_dirty_io(bdi) || bdi == &noop_backing_dev_info)
> @@ -2538,6 +2536,7 @@ void sync_inodes_sb(struct super_block *sb)
> .done = &done,
> .reason = WB_REASON_SYNC,
> .for_sync = 1,
> + .auto_free = 0,
> };
No need for explicit initialization to 0 - that is implicit with the
initializers.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] writeback: clear auto_free in initializaiton
2020-08-26 16:11 ` Jan Kara
@ 2020-09-02 14:49 ` Tejun Heo
0 siblings, 0 replies; 3+ messages in thread
From: Tejun Heo @ 2020-09-02 14:49 UTC (permalink / raw)
To: Jan Kara; +Cc: trix, viro, linux-fsdevel, linux-kernel
Hello,
On Wed, Aug 26, 2020 at 06:11:26PM +0200, Jan Kara wrote:
> > Which seems like a strange place to set auto_free as
> > it is not where the rest of base_work is initialized.
>
> Otherwise I agree it's a strange place. I've added Tejun to CC just in case
> he remembers why he's added that.
I don't remember exactly but maybe I was trying to mirror the
CGROUP_WRITEBACK counterpart without actually thinking about it? The patch
looks good to me.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-09-02 14:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-18 14:13 [PATCH] writeback: clear auto_free in initializaiton trix
2020-08-26 16:11 ` Jan Kara
2020-09-02 14:49 ` Tejun Heo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).