Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Subject: Re: [PATCH 1/2] gfs2: remove usage of list iterator variable for
 list_for_each_entry_continue()
From:   Jakob Koschel <jakobkoschel@gmail.com>
In-Reply-To: <CAHc6FU4s952rPPsceefvZER8dPM9RVWyQrmneMyqaW_0oViFSA@mail.gmail.com>
Date:   Fri, 8 Apr 2022 02:09:05 +0200
Cc:     Bob Peterson <rpeterso@redhat.com>,
        cluster-devel <cluster-devel@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Mike Rapoport <rppt@kernel.org>,
        Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
        Cristiano Giuffrida <c.giuffrida@vu.nl>,
        "Bos, H.J." <h.j.bos@vu.nl>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EB429B0-8A2F-4247-8F84-F6A78BD030F0@gmail.com>
References: <20220331223857.902911-1-jakobkoschel@gmail.com>
 <CAHc6FU4s952rPPsceefvZER8dPM9RVWyQrmneMyqaW_0oViFSA@mail.gmail.com>
To:     Andreas Gruenbacher <agruenba@redhat.com>
Precedence: bulk


> On 4. Apr 2022, at 16:58, Andreas Gruenbacher <agruenba@redhat.com> =
wrote:
>=20
> Hi Jakob,
>=20
> 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].
>>=20
>> Since that variable should not be used past the loop iteration, a
>> separate variable is used to 'remember the current location within =
the
>> loop'.
>>=20
>> To either continue iterating from that position or start a new
>> iteration (if the previous iteration was complete) =
list_prepare_entry()
>> is used.
>=20
> 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.
=46rom 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.

>=20
>> Link: =
https://lore.kernel.org/all/CAHk-=3DwgRr_D8CB-D9Kg-c=3DEHreAsk5SqXPwr9Y7k9=
sA6cWXJ6w@mail.gmail.com/ [1]
>> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
>> ---
>> fs/gfs2/lops.c | 16 ++++++++++++----
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>=20
>> 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 =3D NULL, *bd2;
>> + struct gfs2_bufdata *bd1 =3D 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,
>>=20
>> gfs2_log_lock(sdp);
>> list_sort(NULL, blist, blocknr_cmp);
>> - bd1 =3D bd2 =3D list_prepare_entry(bd1, blist, bd_list);
>> + tmp1 =3D tmp2 =3D list_prepare_entry(bd1, blist, bd_list);
>=20
> 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 =3D 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.

>=20

[1] =
https://lore.kernel.org/linux-kernel/20220308171818.384491-1-jakobkoschel@=
gmail.com/

Thanks,
Jakob