> On 1. Apr 2022, at 01:48, Andrew Morton <[email protected]> wrote:
>
> On Fri, 1 Apr 2022 00:37:00 +0200 Jakob Koschel <[email protected]> wrote:
>
>> When list_for_each_entry() completes the iteration over the whole list
>> without breaking the loop, the iterator value will be a bogus pointer
>> computed based on the head element.
>>
>> While it is safe to use the pointer to determine if it was computed
>> based on the head element, either with list_entry_is_head() or
>> &pos->member == head, using the iterator variable after the loop should
>> be avoided.
>>
>> In preparation to limit the scope of a list iterator to the list
>> traversal loop, use a dedicated pointer to point to the found element [1].
>>
>> ...
>>
>
> Speaking of limiting scope...
Fair point :-)
I see you have applied this already to the -mm tree. Shall I still move the iterator?
The hope is to remove the 'iter' variable altogether when there are no uses after
the loop anymore.
>
> --- a/fs/proc/kcore.c~fs-proc-kcorec-remove-check-of-list-iterator-against-head-past-the-loop-body-fix
> +++ a/fs/proc/kcore.c
> @@ -316,7 +316,6 @@ read_kcore(struct file *file, char __use
> size_t page_offline_frozen = 1;
> size_t phdrs_len, notes_len;
> struct kcore_list *m;
> - struct kcore_list *iter;
> size_t tsz;
> int nphdr;
> unsigned long start;
> @@ -480,6 +479,8 @@ read_kcore(struct file *file, char __use
> * the previous entry, search for a matching entry.
> */
> if (!m || start < m->addr || start >= m->addr + m->size) {
> + struct kcore_list *iter;
> +
> m = NULL;
> list_for_each_entry(iter, &kclist_head, list) {
> if (start >= iter->addr &&
> _
>
Jakob
On Fri, 1 Apr 2022 09:19:57 +0200 Jakob Koschel <[email protected]> wrote:
> > Speaking of limiting scope...
>
> Fair point :-)
>
> I see you have applied this already to the -mm tree. Shall I still move the iterator?
> The hope is to remove the 'iter' variable altogether when there are no uses after
> the loop anymore.
I don't really understand the question.
My plan is to merge your patch with my fixlet immediately prior to
sending upstream.
> On 5. Apr 2022, at 00:55, Andrew Morton <[email protected]> wrote:
>
> On Fri, 1 Apr 2022 09:19:57 +0200 Jakob Koschel <[email protected]> wrote:
>
>>> Speaking of limiting scope...
>>
>> Fair point :-)
>>
>> I see you have applied this already to the -mm tree. Shall I still move the iterator?
>> The hope is to remove the 'iter' variable altogether when there are no uses after
>> the loop anymore.
>
> I don't really understand the question.
Basically I was asking if I should send a v2 with the change you suggested.
>
> My plan is to merge your patch with my fixlet immediately prior to
> sending upstream.
ok, great. Even better, so ignore my question.
Thanks,
Jakob