Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Add some missing error propagation
Date: Mon, 5 Jun 2023 15:54:27 +0100	[thread overview]
Message-ID: <4bfc14c0-19f3-459c-f71c-1b6a92c46d69@linux.intel.com> (raw)
In-Reply-To: <b47de249-085d-482a-afb2-eee82a06aba8@kadam.mountain>


On 05/06/2023 14:43, Dan Carpenter wrote:
> On Mon, Jun 05, 2023 at 02:11:35PM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Add some missing error propagation in live_parallel_switch.
>>
>> To avoid needlessly burdening the various backport processes, note I am
>> not marking it as a fix against any patches and not copying stable since
>> it is debug/selftests only code.
>>
> 
> This patch is unlikely to make a difference in real life, but I don't
> think avoiding Fixes tags and backports is the right thing.
> 
> I would add a Fixes tag and not add a stable tag.
> 
> The real burden with Fixes tags is if it breaks someone's system.  But
> if it's breaking selftests then hopefully those are the people best
> able to deal with it.
> 
> Fixes tags are different from stable tags.  If the code is very recent
> then the fixes tag can automatically allow us to filter out that patch
> from going back to stable.  So for new patches Fixes is the opposite of
> CC'ing stable.
> 
> If the bug is old, then adding a Fixes tag does increase the chance of a
> backport though, that's true.
> 
> My guess is that if the stable maintainers thought that selftests/ were
> causing too much issue with backports they would add a grep line to
> their scripts to solve that problem.  Instead we were having the
> opposite discussion the other week where the bpf people didn't want to
> backport selftest stuff and Greg wanted to.

I just don't see the benefit since to my knowledge no one outside our CI systems runs selftests. And this implies mostly the current development kernel is tested. So backporting is irrelevant.

Even with just the Fixes: tags the internal tooling will be picking the patches up during the -rc phase and even that can cause conflicts and some mental load to maintainers.

Granted, *if* patch truly is a fix for a selftest failure which can actually happen then it is useful to pick it up for the -rc window. Although that feels extremely rare, otherwise it would have been spotted much before.

In any case, I struggle to make myself interested into Fixes: tag for "impossible" selftests failures.

But I can also put them in, 99% of time is not a big deal:

Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in parallel")
Fixes: 6407cf533217 ("drm/i915/selftests: Stop using kthread_stop()")

Stable is even worse since to handle them the pointless workload is even bigger. But if stable wants everything sure, we can send everything. :)

Cc: <stable@vger.kernel.org> # v5.5+

As long as it is accepted that it is unlikely no one will bother to create conflict free backports for all kernels where those don't apply.

Regards,

Tvrtko

> https://lore.kernel.org/all/2023052647-tacking-wince-85c5@gregkh/
> 
> regards,
> dan carpenter
> 

  reply	other threads:[~2023-06-05 14:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 13:11 [Intel-gfx] [PATCH] drm/i915/selftests: Add some missing error propagation Tvrtko Ursulin
2023-06-05 13:43 ` Dan Carpenter
2023-06-05 14:54   ` Tvrtko Ursulin [this message]
2023-06-05 13:47 ` Andi Shyti
2023-06-06  9:44   ` Tvrtko Ursulin
2023-06-05 15:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-06-05 15:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-06-06 11:21 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=4bfc14c0-19f3-459c-f71c-1b6a92c46d69@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dan.carpenter@linaro.org \
    --cc=dri-devel@lists.freedesktop.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