From: Patrick Wang <patrick.wang.shcn@gmail.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, yee.lee@mediatek.com
Subject: Re: [PATCH v2 3/4] mm: kmemleak: handle address stored in object based on its type
Date: Tue, 7 Jun 2022 22:36:06 +0800 [thread overview]
Message-ID: <da096aaf-87b8-e322-1622-4acd28e37dea@gmail.com> (raw)
In-Reply-To: <Yp4Wwtg1uxZ9NLTw@arm.com>
On 2022/6/6 23:01, Catalin Marinas wrote:
> On Fri, Jun 03, 2022 at 11:54:14AM +0800, Patrick Wang wrote:
>> Treat the address stored in object in different way according
>> to its type:
>>
>> - Only use kasan_reset_tag for virtual address
>> - Only update min_addr and max_addr for virtual address
>> - Convert physical address to virtual address in scan_object
>>
>> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
>> Signed-off-by: Patrick Wang <patrick.wang.shcn@gmail.com>
>> ---
>> mm/kmemleak.c | 34 ++++++++++++++++++++++++----------
>> 1 file changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
>> index 218144392446..246a70b7218f 100644
>> --- a/mm/kmemleak.c
>> +++ b/mm/kmemleak.c
>> @@ -297,7 +297,9 @@ static void hex_dump_object(struct seq_file *seq,
>> warn_or_seq_printf(seq, " hex dump (first %zu bytes):\n", len);
>> kasan_disable_current();
>> warn_or_seq_hex_dump(seq, DUMP_PREFIX_NONE, HEX_ROW_SIZE,
>> - HEX_GROUP_SIZE, kasan_reset_tag((void *)ptr), len, HEX_ASCII);
>> + HEX_GROUP_SIZE, object->flags & OBJECT_PHYS ? ptr :
>> + kasan_reset_tag((void *)ptr),
>> + len, HEX_ASCII);
>> kasan_enable_current();
>> }
>
> This will go wrong since ptr is the actual physical address, it cannot
> be dereferenced. This should only be used on virtual pointers and this
> is the case already as we never print unreferenced objects from the phys
> tree. What we could do though is something like an early exit from this
> function (together with a comment that it doesn't support dumping such
> objects):
>
> if (WARN_ON_ONCE(object->flags & OBJECT_PHYS))
> return;
>
I also found this. Will do.
>>
>> @@ -389,14 +391,15 @@ static struct kmemleak_object *lookup_object(unsigned long ptr, int alias,
>> {
>> struct rb_node *rb = is_phys ? object_phys_tree_root.rb_node :
>> object_tree_root.rb_node;
>> - unsigned long untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr);
>> + unsigned long untagged_ptr = is_phys ? ptr : (unsigned long)kasan_reset_tag((void *)ptr);
>>
>> while (rb) {
>> struct kmemleak_object *object;
>> unsigned long untagged_objp;
>>
>> object = rb_entry(rb, struct kmemleak_object, rb_node);
>> - untagged_objp = (unsigned long)kasan_reset_tag((void *)object->pointer);
>> + untagged_objp = is_phys ? object->pointer :
>> + (unsigned long)kasan_reset_tag((void *)object->pointer);
>>
>> if (untagged_ptr < untagged_objp)
>> rb = object->rb_node.rb_left;
>
> You could leave this unchanged. A phys pointer is already untagged, so
> it wouldn't make any difference.
Right, will do.
>
>> @@ -643,16 +646,19 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
>>
>> raw_spin_lock_irqsave(&kmemleak_lock, flags);
>>
>> - untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr);
>> - min_addr = min(min_addr, untagged_ptr);
>> - max_addr = max(max_addr, untagged_ptr + size);
>> + untagged_ptr = is_phys ? ptr : (unsigned long)kasan_reset_tag((void *)ptr);
>
> Same here.
Will do.
>
>> + if (!is_phys) {
>> + min_addr = min(min_addr, untagged_ptr);
>> + max_addr = max(max_addr, untagged_ptr + size);
>> + }
>> link = is_phys ? &object_phys_tree_root.rb_node :
>> &object_tree_root.rb_node;
>> rb_parent = NULL;
>> while (*link) {
>> rb_parent = *link;
>> parent = rb_entry(rb_parent, struct kmemleak_object, rb_node);
>> - untagged_objp = (unsigned long)kasan_reset_tag((void *)parent->pointer);
>> + untagged_objp = is_phys ? parent->pointer :
>> + (unsigned long)kasan_reset_tag((void *)parent->pointer);
>
> And here.
Will do.
>
>> if (untagged_ptr + size <= untagged_objp)
>> link = &parent->rb_node.rb_left;
>> else if (untagged_objp + parent->size <= untagged_ptr)
>> @@ -1202,7 +1208,9 @@ static bool update_checksum(struct kmemleak_object *object)
>>
>> kasan_disable_current();
>> kcsan_disable_current();
>> - object->checksum = crc32(0, kasan_reset_tag((void *)object->pointer), object->size);
>> + object->checksum = crc32(0, object->flags & OBJECT_PHYS ? (void *)object->pointer :
>> + kasan_reset_tag((void *)object->pointer),
>> + object->size);
>
> Luckily that's never called on a phys object, otherwise *object->pointer
> would segfault. As for hex_dump, just return early with a warning if
> that's the case.
Right, will do.
Thanks,
Patrick
next prev parent reply other threads:[~2022-06-07 14:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 3:54 [PATCH v2 0/4] mm: kmemleak: store objects allocated with physical address separately and check when scan Patrick Wang
2022-06-03 3:54 ` [PATCH v2 1/4] mm: kmemleak: add OBJECT_PHYS flag for objects allocated with physical address Patrick Wang
2022-06-06 11:55 ` Catalin Marinas
2022-06-07 14:32 ` Patrick Wang
2022-06-09 9:54 ` Catalin Marinas
2022-06-03 3:54 ` [PATCH v2 2/4] mm: kmemleak: add rbtree " Patrick Wang
2022-06-06 14:38 ` Catalin Marinas
2022-06-07 14:34 ` Patrick Wang
2022-06-03 3:54 ` [PATCH v2 3/4] mm: kmemleak: handle address stored in object based on its type Patrick Wang
2022-06-06 15:01 ` Catalin Marinas
2022-06-07 14:36 ` Patrick Wang [this message]
2022-06-03 3:54 ` [PATCH v2 4/4] mm: kmemleak: kmemleak_*_phys() set address type and check PA when scan Patrick Wang
2022-06-06 15:29 ` Catalin Marinas
2022-06-07 14:37 ` Patrick Wang
2022-06-03 11:01 ` [PATCH v2 0/4] mm: kmemleak: store objects allocated with physical address separately and check " Catalin Marinas
2022-06-04 3:01 ` patrick wang
2022-06-08 2:46 ` Kuan-Ying Lee
2022-06-08 23:44 ` patrick wang
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=da096aaf-87b8-e322-1622-4acd28e37dea@gmail.com \
--to=patrick.wang.shcn@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=yee.lee@mediatek.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.