similar to: [PATCH] drm/nouveau/dispnv04: fix a possible null pointer dereference

Reviewed-by: Lyude Paul <lyude at redhat.com> On Tue, 2024-06-25 at 16:18 +0800, Ma Ke wrote: > In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() > is > assigned to mode, which will lead to a possible NULL pointer > dereference > on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Cc: stable at vger.kernel.org > Signed-off-by: Ma Ke

> In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). Add a check to avoid npd. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. Signed-off-by: Ma Ke <make_ruc2021 at 163.com> --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 ++++ 1 file changed, 4 insertions(+)

Reviewed-by: Lyude Paul <lyude at redhat.com> I will push this and the other patch that you sent upstream in just a moment, thanks! On Tue, 2024-06-25 at 16:10 +0800, Ma Ke wrote: > In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() > is > assigned to mode, which will lead to a possible NULL pointer > dereference > on failure of drm_mode_duplicate(). The

On Wed, 26 Jun 2024, Ma Ke <make24 at iscas.ac.cn> wrote: > In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. > > Signed-off-by: Ma Ke <make24 at iscas.ac.cn> > --- >

> In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. A) Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is > assigned to mode, which will lead to a possible NULL pointer dereference > on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). > Add a check to avoid null pointer dereference. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local

> In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. 1. Can a wording approach (like the following) be a better change description? A null pointer is stored in the local variable ?mode? after a call of the function

Reviewed-by: Lyude Paul <lyude at redhat.com> Will push this upstream in just a moment, thanks! On Thu, 2024-06-27 at 10:27 +0800, Ma Ke wrote: > In nouveau_connector_get_modes(), the return value of > drm_mode_duplicate() > is assigned to mode, which will lead to a possible NULL pointer > dereference on failure of drm_mode_duplicate(). Add a check to avoid > npd. > >

Ma Ke - I assume you already know but you can just ignore this message from Markus as it is just spam. Sorry about the trouble! Markus, you've already been asked by Greg so I will ask a bit more sternly in case there is actually a person on the other end: you've already been asked to stop by Greg and are being ignored by multiple kernel maintainers. If I keep seeing messages like this

On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > On 19.02.2020 21:35, Ville Syrjala wrote: > > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > > > Get rid of mode->vrefresh and just calculate it on demand. Saves > > a bit of space and avoids the cached value getting out of sync > > with reality. > > > > Mostly done

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Get rid of mode->vrefresh and just calculate it on demand. Saves a bit of space and avoids the cached value getting out of sync with reality. Mostly done with cocci, with the following manual fixups: - Remove the now empty loop in drm_helper_probe_single_connector_modes() - Fix __MODE() macro in ch7006_mode.c - Fix DRM_MODE_ARG()

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

On 19.02.2020 21:35, Ville Syrjala wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Get rid of mode->vrefresh and just calculate it on demand. Saves > a bit of space and avoids the cached value getting out of sync > with reality. > > Mostly done with cocci, with the following manual fixups: > - Remove the now empty loop in

On 25.02.2020 12:21, Ville Syrj?l? wrote: > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: >> On 19.02.2020 21:35, Ville Syrjala wrote: >>> From: Ville Syrj?l? <ville.syrjala at linux.intel.com> >>> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves >>> a bit of space and avoids the cached value getting out of

HDMI specification 1.4a, table 8-15 is very explicitly a "must support at least one of" table, not a "must support all of" table. It is not hard to find hardware that does not support some of the so-called "mandatory" modes. More seriously, this code generates invalid display modes for both of the 3D-capable panels that I have (a 42-inch LG TV and a Sony PlayStation

The NULL initialization of the pointers assigned by kzalloc() or kunit_kzalloc() first is not necessary, because if the kzalloc() or kunit_kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Ruan Jinjie (7): drm/amdkfd: Remove unnecessary NULL values drm/amd/display: Remove unnecessary NULL values drm/msm: Remove unnecessary NULL values

From: Ville Syrj?l? <ville.syrjala at linux.intel.com> Get rid of mode->vrefresh and just calculate it on demand. Saves a bit of space and avoids the cached value getting out of sync with reality. Mostly done with cocci, with the following manual fixups: - Remove the now empty loop in drm_helper_probe_single_connector_modes() - Fix __MODE() macro in ch7006_mode.c - Fix DRM_MODE_ARG()

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---