From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Jakob Koschel <jakobkoschel@gmail.com>
Cc: Mark Fasheh <mark@fasheh.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ocfs2-devel@oss.oracle.com, Joel Becker <jlbec@evilplan.org>,
Andrew Morton <akpm@linux-foundation.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Miguel Ojeda <ojeda@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>,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH] ocfs2: fix check if list iterator did find an element
Date: Tue, 22 Mar 2022 10:15:34 +0800 [thread overview]
Message-ID: <5aefc78f-9a75-9b44-9471-87f42011b7c2@linux.alibaba.com> (raw)
In-Reply-To: <A7AA04AA-6B4C-4211-99A6-0D3C04ED7B26@gmail.com>
On 3/21/22 9:34 PM, Jakob Koschel wrote:
>
>> On 21. Mar 2022, at 02:50, Joseph Qi <joseph.qi@linux.alibaba.com> wrote:
>>
>>
>>
>> On 3/20/22 4:31 AM, Jakob Koschel wrote:
>>> Instead of setting 'res' to NULL, it should only be set if
>>> the suitable element was found.
>>>
>>> In the original code 'res' would have been set to an incorrect pointer
>>> if the list is empty.
>>>
>> The logic before iteration can make sure track_list won't be empty.
>> Please refer the discussion via:
>> https://lore.kernel.org/ocfs2-devel/bd0ec87e-b490-83dc-2363-5e5342c59fa4@linux.alibaba.com/T/#m96d4397930201d83d68677c33a9721ae8dbd8f15
>
> ah yes, I just read up on the discussion there, sorry for having duplicated it
> here.
>
> Was any conclusion reached there which fixes can/should be merged?
>
> This code obviously can always be safe if the list cannot be empty.
> That's also not necessarily the reason I'm fixing this. The reason is that
> we want to get rid of any use of the list iterator variable after the loop
> ('res' in this case). This will allow moving the list iterator variable
> into the scope of the list iterator macro to forbid any invalid use of it
> at compile time. Like this you don't have to rely on assumptions that are
> hard to validate (e.g. that a certain list is never empty).
>
> The patch here is the minimal change to simply do that but looking at
> Dan Carpenter patch there might be more things in this code that can
> be simplified.
>
Agree, so I'm fine with this change.
So could you please update the description and send v2?
Thanks,
Joseph
> [CC'd Dan Carpenter]
>
> See [1] for changes that have already been merged:
>
> [1] https://lore.kernel.org/linux-kernel/20220308171818.384491-3-jakobkoschel@gmail.com/
>
>>
>> Thanks,
>> Joseph
>>
>>> In preparation to limit the scope of the list iterator to the list
>>> traversal loop, use a dedicated pointer pointing to the found element [1].
>>>
>>> Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/
>>> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
>>> ---
>>> fs/ocfs2/dlm/dlmdebug.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/fs/ocfs2/dlm/dlmdebug.c b/fs/ocfs2/dlm/dlmdebug.c
>>> index d442cf5dda8a..be5e9ed7da8d 100644
>>> --- a/fs/ocfs2/dlm/dlmdebug.c
>>> +++ b/fs/ocfs2/dlm/dlmdebug.c
>>> @@ -541,7 +541,7 @@ static void *lockres_seq_start(struct seq_file *m, loff_t *pos)
>>> struct debug_lockres *dl = m->private;
>>> struct dlm_ctxt *dlm = dl->dl_ctxt;
>>> struct dlm_lock_resource *oldres = dl->dl_res;
>>> - struct dlm_lock_resource *res = NULL;
>>> + struct dlm_lock_resource *res = NULL, *iter;
>>> struct list_head *track_list;
>>>
>>> spin_lock(&dlm->track_lock);
>>> @@ -556,11 +556,11 @@ static void *lockres_seq_start(struct seq_file *m, loff_t *pos)
>>> }
>>> }
>>>
>>> - list_for_each_entry(res, track_list, tracking) {
>>> - if (&res->tracking == &dlm->tracking_list)
>>> - res = NULL;
>>> - else
>>> - dlm_lockres_get(res);
>>> + list_for_each_entry(iter, track_list, tracking) {
>>> + if (&iter->tracking != &dlm->tracking_list) {
>>> + dlm_lockres_get(iter);
>>> + res = iter;
>>> + }
>>> break;
>>> }
>>> spin_unlock(&dlm->track_lock);
>>>
>>> base-commit: 34e047aa16c0123bbae8e2f6df33e5ecc1f56601
>>> --
>>> 2.25.1
>
> Jakob
prev parent reply other threads:[~2022-03-22 2:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-19 20:31 [PATCH] ocfs2: fix check if list iterator did find an element Jakob Koschel
2022-03-21 1:50 ` Joseph Qi
2022-03-21 13:34 ` Jakob Koschel
2022-03-21 13:54 ` Dan Carpenter
2022-03-21 16:00 ` David Laight
2022-03-21 16:22 ` Dan Carpenter
2022-03-22 2:15 ` Joseph Qi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5aefc78f-9a75-9b44-9471-87f42011b7c2@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=bjohannesmeyer@gmail.com \
--cc=c.giuffrida@vu.nl \
--cc=dan.carpenter@oracle.com \
--cc=geert@linux-m68k.org \
--cc=h.j.bos@vu.nl \
--cc=jakobkoschel@gmail.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=masahiroy@kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
--cc=ojeda@kernel.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox