Messages in this thread | | | Subject | Re: [PATCH 1/2] gfs2: remove usage of list iterator variable for list_for_each_entry_continue() | From | Jakob Koschel <> | Date | Fri, 8 Apr 2022 02:09:05 +0200 |
| |
> On 4. Apr 2022, at 16:58, Andreas Gruenbacher <agruenba@redhat.com> wrote: > > Hi Jakob, > > On Fri, Apr 1, 2022 at 12:40 AM Jakob Koschel <jakobkoschel@gmail.com> wrote: >> In preparation to limiting the scope of a list iterator to the list >> traversal loop, use a dedicated pointer to iterate through the list [1]. >> >> Since that variable should not be used past the loop iteration, a >> separate variable is used to 'remember the current location within the >> loop'. >> >> To either continue iterating from that position or start a new >> iteration (if the previous iteration was complete) list_prepare_entry() >> is used. > > I can see how accessing an iterator variable past a for_each_entry > loop will cause problems when it ends up pointing at the list head.
Well, as long as you only use it to access the list head, there should be no problem, hence no bug.
The issue are more the cases that use other members of that 'bogus' pointer and there were plenty of such cases [1]. That's why the goal is to "not use the iterator variable after the loop" so the scope can be lowered and such cases are avoided by construction.
> Here, the iterator variables are not accessed outside the loops at > all, though. So this patch is ugly, and it doesn't even help.
I do agree that this patch is ugly. I'm open to suggestions on how to improve the code allowing to lower the scope of 'bd1' to the traversal loop. But I don't agree that the iterator variables are not used outside of the loops. (If with loops you mean the list traversals).
The iterator variables are not used "after" in terms of code location but since it's wrapped by a while loop they are used "after" in regards of execution time. From the second iteration of the while loop onwards, it will used the leftover 'bd1' pointer from the previous iterations list traversal, hence using the variables "outside of the traversal loops". Lowering the scope will not be possible because of this.
> >> Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] >> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> >> --- >> fs/gfs2/lops.c | 16 ++++++++++++---- >> 1 file changed, 12 insertions(+), 4 deletions(-) >> >> diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c >> index 6ba51cbb94cf..74e6d05cee2c 100644 >> --- a/fs/gfs2/lops.c >> +++ b/fs/gfs2/lops.c >> @@ -653,7 +653,7 @@ static void gfs2_before_commit(struct gfs2_sbd *sdp, unsigned int limit, >> bool is_databuf) >> { >> struct gfs2_log_descriptor *ld; >> - struct gfs2_bufdata *bd1 = NULL, *bd2; >> + struct gfs2_bufdata *bd1 = NULL, *bd2, *tmp1, *tmp2; >> struct page *page; >> unsigned int num; >> unsigned n; >> @@ -661,7 +661,7 @@ static void gfs2_before_commit(struct gfs2_sbd *sdp, unsigned int limit, >> >> gfs2_log_lock(sdp); >> list_sort(NULL, blist, blocknr_cmp); >> - bd1 = bd2 = list_prepare_entry(bd1, blist, bd_list); >> + tmp1 = tmp2 = list_prepare_entry(bd1, blist, bd_list); > > We should actually be using list_entry() here, not list_prepare_entry().
I'm not sure if you are referring to using list_entry() here in the original or in the changed version.
I don't see how that would be much better in either cases. 'bd1' can be NULL in both cases which would break when simply using list_entry(). In the original code, 'bd1' would be NULL for the first iteration of the while loop and in the updated version it would be NULL in the first iteration + every time the list traversal in the previous iteration did not break early.
Just using 'bd1 = list_entry(bd1, blist, bd_list);' when initializing would work in the original code. But it's not solving the scope issue where 'bd1' is used outside of the list traversal loop.
>
[1] https://lore.kernel.org/linux-kernel/20220308171818.384491-1-jakobkoschel@gmail.com/
Thanks, Jakob
| |