similar to: nv50_disp_chan_mthd: ensure mthd is not NULL

Pointer to structure array is assumed not NULL by default. It has the consequence to raise a kernel panic when it's not the case. Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the reason

Hi Fr?d?ric, It appears Ben made his own version of this patch (probably based on the one you added to the kernel bz), and it's already upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2 Cheers, -ilia On Thu, Feb 20, 2020 at 12:19 PM Fr?d?ric Pierret <frederic.pierret at qubes-os.org>

On Wed, Jan 29, 2020 at 05:22:13PM +0100, Fr?d?ric Pierret wrote: > Dear Ben Skeggs, > > Please find attached a patch solving a blocking issue I encountered: > https://bugzilla.kernel.org/show_bug.cgi?id=206299 > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the

Hi, Is anything missing here? How can I get this merged? Best regards, Fr?d?ric Pierret On 2020-02-08 20:43, Fr?d?ric Pierret wrote: > Pointer to structure array is assumed not NULL by default. It has > the consequence to raise a kernel panic when it's not the case. > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd'

From: Colin Ian King <colin.king at canonical.com> The constant values being shifted are 32 bit integers and may potentially overflow on the shift. Avoid this potential overflow by making them unsigned long long values before the shift. Detected by CoverityScan, CID#1469383, 1469400 ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king at

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

Current code disables fbcon acceleration before fbcon is suspended, leading to corrupted console after resume from s2disk. In a similar fashion we must make sure that fbcon acceleration is enabled before we revive the console. With this patch s2disk works correctly on my MacBookPro6,2 with GT216 [GeForce GT 330M] hibernate: kernel: nouveau [ DRM] suspending fbcon... kernel: nouveau [

On Fri, Apr 20, 2018 at 09:18:01PM +0300, Michael S. Tsirkin wrote: > an allocated buffer doesn't need to be tied to a vq - > only vq->vdev is ever used. Pass the function the > just what it needs - the vdev. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/char/virtio_console.c | 14 +++++++------- > 1 file changed, 7 insertions(+),

On Fri, Apr 20, 2018 at 09:18:01PM +0300, Michael S. Tsirkin wrote: > an allocated buffer doesn't need to be tied to a vq - > only vq->vdev is ever used. Pass the function the > just what it needs - the vdev. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/char/virtio_console.c | 14 +++++++------- > 1 file changed, 7 insertions(+),

Hello Ben Skeggs, The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts" from May 8, 2018, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:169 nv50_disp_chan_intr() warn: should '65537 << chan->chid.user' be a 64 bit type?

On Tue, Nov 19, 2013 at 05:59:13PM +0100, Christoph Rudorff wrote: > Current code disables fbcon acceleration before fbcon is suspended, > leading to corrupted console after resume from s2disk. In a similar > fashion we must make sure that fbcon acceleration is enabled before we > revive the console. > > With this patch s2disk works correctly on my MacBookPro6,2 with GT216 >

cc to Greg for 3.9. > On Tue, May 28, 2013 at 04:54:44PM +0800, Wenchao Xia wrote: >> ioctl for VHOST_SCSI_SET_ENDPOINT report file exist errori, when I forget >> to set it correctly in configfs, make user confused. Actually it fail >> to find a matching one, so change the error value. >> >> Signed-off-by: Wenchao Xia <wenchaolinux at gmail.com> > >

cc to Greg for 3.9. > On Tue, May 28, 2013 at 04:54:44PM +0800, Wenchao Xia wrote: >> ioctl for VHOST_SCSI_SET_ENDPOINT report file exist errori, when I forget >> to set it correctly in configfs, make user confused. Actually it fail >> to find a matching one, so change the error value. >> >> Signed-off-by: Wenchao Xia <wenchaolinux at gmail.com> > >

We get 2 warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] In fact, these functions are declared in

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous