All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Brian Norris <briannorris@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sandy Huang <hjc@rock-chips.com>,
	Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state()
Date: Fri, 24 Jun 2022 22:37:50 +0200	[thread overview]
Message-ID: <4134988.X513TT2pbd@phil> (raw)
In-Reply-To: <CA+ASDXOzhoooDDJUWV7rKpz-7GkMR5v=3gKQt4XazTSgnY51WQ@mail.gmail.com>

Am Freitag, 24. Juni 2022, 19:57:53 CEST schrieb Brian Norris:
> On Fri, Jun 24, 2022 at 12:23 AM Heiko Stuebner <heiko@sntech.de> wrote:
> > The interesting question would be, do we want some fixes tag for it?
> 
> I'm not aware of any currently-upstream code that will hit this [1].
> I've hit it in out-of-tree code (or, code that I submitted to
> dri-devel, but wasn't accepted as-is), and this is the "belt and
> braces" part -- the primary fix is that we should avoid calling things
> like drm_atomic_get_crtc_state() at inappropriate times.
> 
> So, is the "extra safety" check really something that should go to
> -stable? (Because let's be honest, everything with a Fixes tag goes
> there.) Maybe?
> 
> Anyway, if you want to "blame" anything, this commit actually dropped
> the safety check:
> 
> 4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config

I tend to think, if we know that connection we should also include it :-) .
I wouldn't include a cc-stable for the reason you mentioned, but to me
it makes sense if someone reading the git history in the future can easily
know that information - so it doesn't hurt :-) .

So I'll add that when applying.

Thanks for supplying the origin commit
Heiko

> 
> Brian
> 
> [1] But I'm not omniscient. So maybe it's good to have anyway.
> 





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Brian Norris <briannorris@chromium.org>
Cc: David Airlie <airlied@linux.ie>,
	Doug Anderson <dianders@chromium.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Sandy Huang <hjc@rock-chips.com>,
	Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state()
Date: Fri, 24 Jun 2022 22:37:50 +0200	[thread overview]
Message-ID: <4134988.X513TT2pbd@phil> (raw)
In-Reply-To: <CA+ASDXOzhoooDDJUWV7rKpz-7GkMR5v=3gKQt4XazTSgnY51WQ@mail.gmail.com>

Am Freitag, 24. Juni 2022, 19:57:53 CEST schrieb Brian Norris:
> On Fri, Jun 24, 2022 at 12:23 AM Heiko Stuebner <heiko@sntech.de> wrote:
> > The interesting question would be, do we want some fixes tag for it?
> 
> I'm not aware of any currently-upstream code that will hit this [1].
> I've hit it in out-of-tree code (or, code that I submitted to
> dri-devel, but wasn't accepted as-is), and this is the "belt and
> braces" part -- the primary fix is that we should avoid calling things
> like drm_atomic_get_crtc_state() at inappropriate times.
> 
> So, is the "extra safety" check really something that should go to
> -stable? (Because let's be honest, everything with a Fixes tag goes
> there.) Maybe?
> 
> Anyway, if you want to "blame" anything, this commit actually dropped
> the safety check:
> 
> 4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config

I tend to think, if we know that connection we should also include it :-) .
I wouldn't include a cc-stable for the reason you mentioned, but to me
it makes sense if someone reading the git history in the future can easily
know that information - so it doesn't hurt :-) .

So I'll add that when applying.

Thanks for supplying the origin commit
Heiko

> 
> Brian
> 
> [1] But I'm not omniscient. So maybe it's good to have anyway.
> 





WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Brian Norris <briannorris@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sandy Huang <hjc@rock-chips.com>,
	Sean Paul <seanpaul@chromium.org>
Subject: Re: [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state()
Date: Fri, 24 Jun 2022 22:37:50 +0200	[thread overview]
Message-ID: <4134988.X513TT2pbd@phil> (raw)
In-Reply-To: <CA+ASDXOzhoooDDJUWV7rKpz-7GkMR5v=3gKQt4XazTSgnY51WQ@mail.gmail.com>

Am Freitag, 24. Juni 2022, 19:57:53 CEST schrieb Brian Norris:
> On Fri, Jun 24, 2022 at 12:23 AM Heiko Stuebner <heiko@sntech.de> wrote:
> > The interesting question would be, do we want some fixes tag for it?
> 
> I'm not aware of any currently-upstream code that will hit this [1].
> I've hit it in out-of-tree code (or, code that I submitted to
> dri-devel, but wasn't accepted as-is), and this is the "belt and
> braces" part -- the primary fix is that we should avoid calling things
> like drm_atomic_get_crtc_state() at inappropriate times.
> 
> So, is the "extra safety" check really something that should go to
> -stable? (Because let's be honest, everything with a Fixes tag goes
> there.) Maybe?
> 
> Anyway, if you want to "blame" anything, this commit actually dropped
> the safety check:
> 
> 4e257d9eee23 drm/rockchip: get rid of rockchip_drm_crtc_mode_config

I tend to think, if we know that connection we should also include it :-) .
I wouldn't include a cc-stable for the reason you mentioned, but to me
it makes sense if someone reading the git history in the future can easily
know that information - so it doesn't hurt :-) .

So I'll add that when applying.

Thanks for supplying the origin commit
Heiko

> 
> Brian
> 
> [1] But I'm not omniscient. So maybe it's good to have anyway.
> 





  reply	other threads:[~2022-06-24 20:38 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18  0:26 [PATCH] drm/rockchip: vop: Don't crash for invalid duplicate_state() Brian Norris
2022-06-18  0:26 ` Brian Norris
2022-06-18  0:26 ` Brian Norris
2022-06-23 16:46 ` Sean Paul
2022-06-23 16:46   ` Sean Paul
2022-06-23 16:46   ` Sean Paul
2022-06-23 23:44 ` Doug Anderson
2022-06-23 23:44   ` Doug Anderson
2022-06-23 23:44   ` Doug Anderson
2022-06-24  7:23   ` Heiko Stuebner
2022-06-24  7:23     ` Heiko Stuebner
2022-06-24  7:23     ` Heiko Stuebner
2022-06-24 17:57     ` Brian Norris
2022-06-24 17:57       ` Brian Norris
2022-06-24 17:57       ` Brian Norris
2022-06-24 20:37       ` Heiko Stuebner [this message]
2022-06-24 20:37         ` Heiko Stuebner
2022-06-24 20:37         ` Heiko Stuebner
2022-07-03 11:11 ` Heiko Stuebner
2022-07-03 11:11   ` Heiko Stuebner
2022-07-03 11:11   ` Heiko Stuebner

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=4134988.X513TT2pbd@phil \
    --to=heiko@sntech.de \
    --cc=airlied@linux.ie \
    --cc=briannorris@chromium.org \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hjc@rock-chips.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=seanpaul@chromium.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 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.