linux-kernel - Re: [PATCH 1/2] gfs2: remove usage of list iterator variable for list_for_each_entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 8 Apr 2022 02:09:05 +0200
From:   Jakob Koschel <jakobkoschel@...il.com>
To:     Andreas Gruenbacher <agruenba@...hat.com>
Cc:     Bob Peterson <rpeterso@...hat.com>,
        cluster-devel <cluster-devel@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Mike Rapoport <rppt@...nel.org>,
        Brian Johannesmeyer <bjohannesmeyer@...il.com>,
        Cristiano Giuffrida <c.giuffrida@...nl>,
        "Bos, H.J." <h.j.bos@...nl>
Subject: Re: [PATCH 1/2] gfs2: remove usage of list iterator variable for
 list_for_each_entry_continue()

> On 4. Apr 2022, at 16:58, Andreas Gruenbacher <agruenba@...hat.com> wrote:
> 
> Hi Jakob,
> 
> On Fri, Apr 1, 2022 at 12:40 AM Jakob Koschel <jakobkoschel@...il.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@...il.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