From: Peter Senna Tschudin <peter.senna@linux.intel.com>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
igt-dev@lists.freedesktop.org, ryszard.knop@intel.com,
lucas.demarchi@intel.com, katarzyna.piecielska@intel.com,
Jonathan Cavitt <jonathan.cavitt@intel.com>
Subject: Re: [PATCH i-g-t v4 2/2] runner/executor: Integrate igt_kmemleak scans
Date: Wed, 12 Feb 2025 15:53:53 +0100 [thread overview]
Message-ID: <aab1271b-5a64-4d9a-b8a7-156ec5b89f68@linux.intel.com> (raw)
In-Reply-To: <20250212142416.tmzmgwu5mtqo7fxm@kamilkon-desk.igk.intel.com>
Hi Kamil,
On 12.02.2025 15:24, Kamil Konieczny wrote:
> Hi Peter,
> On 2025-02-03 at 10:10:53 +0100, Peter Senna Tschudin wrote:
>> Hi Kamil,
>>
>> Thank you for the review.
>>
>> [...]
>>
>>>> igt_facts_lists_init();
>>>>
>>>> + if (settings->kmemleak)
>>>> + if (!igt_kmemleak_init(NULL)) {
>>>> + errf("Failed to initialize kmemleak. Is kernel support enabled?\n");
>>>> + errf("Disabling kmemleak on igt_runner and continuing...\n");
>>>
>>> Make it one errf() call, split string if needed.
>> chekcpatch does not like multi-line strings. Can you show me the code
>> you want me to use here that satisfies you and checkpatch at the same time?
>>
>
> It is a tool and it do happen when developer could ignore it,
> you have one example here and other is for drm structs which
> use camel case names.
So you want a single errf() with a multi line string and you are happy to ignore
checkpatch complaining about it. Cool, will do.
>
>>
>> [...]
>>>
>>>> + settings->kmemleak = settings->kmemleak_each = false;
>>>
>>> Avoid this, write two assinments here.
>>
>> I personally find this very elegant, but sure, I will make the change.
>>
>> [...]
>>
>>>> @@ -718,6 +723,7 @@ igt_main
>>>> igt_subtest("parse-clears-old-data") {
>>>> const char *argv[] = { "runner",
>>>> "-n", "foo",
>>>> + "--overwrite",
>>>
>>> Do not make unrelated changes, add only kmemleak.
>>> You also didn't write about this change in description, if you
>>> think it is a fix it should go in separate patch, not here.
>>
>> These are not unrelated. First as this is unit testing, this has no
>> downstream effects. Second, I am adding --overwrite to grow the argv
>> array. The reason for that is to be able to test the new argument.
>
> Well, I do no understand why are you doing this in this patch?
> When you added facts you change only small fragment but now it
> looks like an unneccecery big change. Please make this change
> small and consider adding all that bigger unrelated changes
> in separate cleanup patch after this one.
I was lucky that there was a free slot on the array for facts. Now I cannot
unit test facts and kmemleak at the same time without growing the array.
Sorry. Do you see an easy way that I am missing?
Thank you,
Peter
next prev parent reply other threads:[~2025-02-12 14:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-28 15:15 [PATCH i-g-t v4 0/2] Integrate kmemleak scans in igt_runner Peter Senna Tschudin
2025-01-28 15:15 ` [PATCH i-g-t v4 1/2] lib/igt_kmemleak: library to interact with kmemleak Peter Senna Tschudin
2025-01-31 12:34 ` Kamil Konieczny
2025-02-03 9:23 ` Peter Senna Tschudin
2025-02-11 16:17 ` Zbigniew Kempczyński
2025-02-11 19:12 ` Peter Senna Tschudin
2025-02-12 8:36 ` Zbigniew Kempczyński
2025-02-12 9:18 ` Peter Senna Tschudin
2025-02-12 10:01 ` Zbigniew Kempczyński
2025-02-12 13:12 ` Peter Senna Tschudin
2025-02-12 13:41 ` Kamil Konieczny
2025-02-12 14:57 ` Peter Senna Tschudin
2025-02-25 13:46 ` Peter Senna Tschudin
2025-02-25 18:06 ` Peter Senna Tschudin
2025-01-31 12:38 ` Kamil Konieczny
2025-02-03 9:14 ` Peter Senna Tschudin
2025-02-12 14:26 ` Kamil Konieczny
2025-01-28 15:15 ` [PATCH i-g-t v4 2/2] runner/executor: Integrate igt_kmemleak scans Peter Senna Tschudin
2025-01-31 12:50 ` Kamil Konieczny
2025-02-03 9:10 ` Peter Senna Tschudin
2025-02-12 14:24 ` Kamil Konieczny
2025-02-12 14:53 ` Peter Senna Tschudin [this message]
2025-01-28 20:48 ` ✓ i915.CI.BAT: success for Integrate kmemleak scans in igt_runner (rev2) Patchwork
2025-01-28 20:49 ` Patchwork
2025-01-28 20:52 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-29 10:40 ` ✗ Xe.CI.Full: failure " Patchwork
2025-01-29 13:18 ` Peter Senna Tschudin
2025-01-29 11:25 ` ✗ i915.CI.Full: " Patchwork
2025-01-29 13:19 ` Peter Senna Tschudin
2025-01-30 6:18 ` Ravali, JupallyX
2025-01-30 5:26 ` ✓ i915.CI.Full: success " Patchwork
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=aab1271b-5a64-4d9a-b8a7-156ec5b89f68@linux.intel.com \
--to=peter.senna@linux.intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=katarzyna.piecielska@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=ryszard.knop@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox