| Message ID | 20211005065151.828922-1-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] drm: Increase DRM_OBJECT_MAX_PROPERTY by 18. | expand |
On Tue, Oct 05, 2021 at 08:51:51AM +0200, Sebastian Andrzej Siewior wrote: > The warning poped up, it says it increase it by the number of occurrence. > I saw it 18 times so here it is. > It started to up since commit > 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") > > Increase DRM_OBJECT_MAX_PROPERTY by 18. > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Which driver where? Whomever added that into upstream should also have realized this (things will just not work) and include it in there. So if things are tested correctly this should be part of a larger series to add these 18 props somewhere. Also maybe we should just dynamically allocate this array if people have this many properties on their objects. -Daniel > --- > > I have no idea whether this is correct or just a symptom of another > problem. This has been observed with i915 and full debug. > > include/drm/drm_mode_object.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h > index c34a3e8030e12..1e5399e47c3a5 100644 > --- a/include/drm/drm_mode_object.h > +++ b/include/drm/drm_mode_object.h > @@ -60,7 +60,7 @@ struct drm_mode_object { > void (*free_cb)(struct kref *kref); > }; > > -#define DRM_OBJECT_MAX_PROPERTY 24 > +#define DRM_OBJECT_MAX_PROPERTY 42 > /** > * struct drm_object_properties - property tracking for &drm_mode_object > */ > -- > 2.33.0 >
On 2021-10-13 14:02:59 [+0200], Daniel Vetter wrote: > On Tue, Oct 05, 2021 at 08:51:51AM +0200, Sebastian Andrzej Siewior wrote: > > The warning poped up, it says it increase it by the number of occurrence. > > I saw it 18 times so here it is. > > It started to up since commit > > 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") > > > > Increase DRM_OBJECT_MAX_PROPERTY by 18. > > > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > Which driver where? Whomever added that into upstream should also have > realized this (things will just not work) and include it in there. So if > things are tested correctly this should be part of a larger series to add > these 18 props somewhere. This is on i915 with full debug. If I remember correctly, it wasn't there before commit c7fcbf2513973 ("drm/plane: check that fb_damage is set up when used") With that commit the box crashed until commit 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") where I then observed this. > Also maybe we should just dynamically allocate this array if people have > this many properties on their objects. > -Daniel Sebastian
On Wed, Oct 13, 2021 at 02:35:25PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-13 14:02:59 [+0200], Daniel Vetter wrote: > > On Tue, Oct 05, 2021 at 08:51:51AM +0200, Sebastian Andrzej Siewior wrote: > > > The warning poped up, it says it increase it by the number of occurrence. > > > I saw it 18 times so here it is. > > > It started to up since commit > > > 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") > > > > > > Increase DRM_OBJECT_MAX_PROPERTY by 18. > > > > > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > > > Which driver where? Whomever added that into upstream should also have > > realized this (things will just not work) and include it in there. So if > > things are tested correctly this should be part of a larger series to add > > these 18 props somewhere. > > This is on i915 with full debug. If I remember correctly, it wasn't > there before commit > c7fcbf2513973 ("drm/plane: check that fb_damage is set up when used") > > With that commit the box crashed until commit > 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") > > where I then observed this. Hm there's a pile of commits there, and nothing immediately jumps to light. The thing is, 18 is likely way too much, since if e.g. we have a single new property on a plane and that pushes over the limit on all of them, you get iirc 3x4 already simply because we have that many planes. So would be good to know the actual culprit. Can you pls try to bisect the above range, applying the patch as a fixup locally (without commit, that will confuse git bisect a bit I think), so we know what/where went wrong? I'm still confused why this isn't showing up anywhere in our intel ci ... Thanks, Daniel > > > Also maybe we should just dynamically allocate this array if people have > > this many properties on their objects. > > -Daniel > > Sebastian
On 2021-10-13 14:57:34 [+0200], Daniel Vetter wrote: > Hm there's a pile of commits there, and nothing immediately jumps to > light. The thing is, 18 is likely way too much, since if e.g. we have a > single new property on a plane and that pushes over the limit on all of > them, you get iirc 3x4 already simply because we have that many planes. > > So would be good to know the actual culprit. > > Can you pls try to bisect the above range, applying the patch as a fixup > locally (without commit, that will confuse git bisect a bit I think), so > we know what/where went wrong? c7fcbf2513973 -> does not boot c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > I'm still confused why this isn't showing up anywhere in our intel ci ... > > Thanks, Daniel Sebastian
On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-13 14:57:34 [+0200], Daniel Vetter wrote: > > Hm there's a pile of commits there, and nothing immediately jumps to > > light. The thing is, 18 is likely way too much, since if e.g. we have a > > single new property on a plane and that pushes over the limit on all of > > them, you get iirc 3x4 already simply because we have that many planes. > > > > So would be good to know the actual culprit. > > > > Can you pls try to bisect the above range, applying the patch as a fixup > > locally (without commit, that will confuse git bisect a bit I think), so > > we know what/where went wrong? > > c7fcbf2513973 -> does not boot > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY > 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY Just to check, you've built 6f11f37459d8f, and then you cherry-picked 2f425cf5242a0 on top (not merged), and that already got you the warning flood? I'm probably blind, but I'm really not seeing where this pile of properties is coming from. Can you pls also boot with drm.debug=0xe and attach full dmesg? Plus your .config please. Thanks, Daniel > > > I'm still confused why this isn't showing up anywhere in our intel ci ... > > > > Thanks, Daniel > > Sebastian
On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote: > On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote: > > c7fcbf2513973 -> does not boot > > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY > > 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > Just to check, you've built 6f11f37459d8f, and then you cherry-picked > 2f425cf5242a0 on top (not merged), and that already got you the warning > flood? Correct. > I'm probably blind, but I'm really not seeing where this pile of > properties is coming from. Can you pls also boot with drm.debug=0xe and > attach full dmesg? Plus your .config please. attached. dmesg.txt is 6f11f37459d8f and the other is 6f11f37459d8f + 2f425cf5242a0. > Thanks, Daniel Sebastian
On Thu, Oct 14, 2021 at 03:47:31PM +0200, Sebastian Andrzej Siewior wrote: > On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote: > > On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote: > > > c7fcbf2513973 -> does not boot > > > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > > 6f11f37459d8f -> boots, 0 x DRM_OBJECT_MAX_PROPERTY > > > 6f11f37459d8f + 2f425cf5242a0 -> boots, 18 x DRM_OBJECT_MAX_PROPERTY > > > > Just to check, you've built 6f11f37459d8f, and then you cherry-picked > > 2f425cf5242a0 on top (not merged), and that already got you the warning > > flood? > > Correct. > > > I'm probably blind, but I'm really not seeing where this pile of > > properties is coming from. Can you pls also boot with drm.debug=0xe and > > attach full dmesg? Plus your .config please. > > attached. dmesg.txt is 6f11f37459d8f and the other is 6f11f37459d8f + > 2f425cf5242a0. Ah dmesg help me understand what's going on. Does the below patch help? If it's this one that would also explain why intel CI hasn't hit it - it's a leak between tests and we run them all individually instead of once at boot-up. Cheers, Daniel diff --git a/drivers/gpu/drm/selftests/test-drm_damage_helper.c b/drivers/gpu/drm/selftests/test-drm_damage_helper.c index 1c19a5d3eefb..8d8d8e214c28 100644 --- a/drivers/gpu/drm/selftests/test-drm_damage_helper.c +++ b/drivers/gpu/drm/selftests/test-drm_damage_helper.c @@ -30,6 +30,7 @@ static void mock_setup(struct drm_plane_state *state) mock_device.driver = &mock_driver; mock_device.mode_config.prop_fb_damage_clips = &mock_prop; mock_plane.dev = &mock_device; + mock_obj_props.count = 0; mock_plane.base.properties = &mock_obj_props; mock_prop.base.id = 1; /* 0 is an invalid id */ mock_prop.dev = &mock_device;
On 2021-10-19 14:24:29 [+0200], Daniel Vetter wrote: > > Ah dmesg help me understand what's going on. Does the below patch help? If > it's this one that would also explain why intel CI hasn't hit it - it's a > leak between tests and we run them all individually instead of once at > boot-up. Yes, it does. Thank you. Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > Cheers, Daniel Sebastian
diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h index c34a3e8030e12..1e5399e47c3a5 100644 --- a/include/drm/drm_mode_object.h +++ b/include/drm/drm_mode_object.h @@ -60,7 +60,7 @@ struct drm_mode_object { void (*free_cb)(struct kref *kref); }; -#define DRM_OBJECT_MAX_PROPERTY 24 +#define DRM_OBJECT_MAX_PROPERTY 42 /** * struct drm_object_properties - property tracking for &drm_mode_object */
The warning poped up, it says it increase it by the number of occurrence. I saw it 18 times so here it is. It started to up since commit 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property") Increase DRM_OBJECT_MAX_PROPERTY by 18. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- I have no idea whether this is correct or just a symptom of another problem. This has been observed with i915 and full debug. include/drm/drm_mode_object.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)