On 21 May 2015 at 06:01, Ilia Mirkin <imirkin@xxxxxxxxxxxx> wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translating into crazy amounts of
> VRAM, which destroys all sorts of other logic down the line. Instead,
> fail device init.
Hrm, I'm not sure what I think of doing something like this. Where do
we draw the line at validating stuff we read from GPU registers?
Either way, we still have a bug, so I'm not sure what we gain from
working around it like this.
Ben.
>
> Signed-off-by: Ilia Mirkin <imirkin@xxxxxxxxxxxx>
> Cc: stable@xxxxxxxxxx
> ---
> drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> index de9f395..9d4d196 100644
> --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c
> @@ -545,6 +545,12 @@ gf100_ram_create_(struct nvkm_object *parent, struct nvkm_object *engine,
> }
> }
>
> + /* if over 1TB of VRAM is reported, something went very wrong, bail */
> + if (ram->size > (1ULL << 40)) {
> + nv_error(pfb, "invalid vram size: %llx\n", ram->size);
> + return -EINVAL;
> + }
> +
> /* if all controllers have the same amount attached, there's no holes */
> if (uniform) {
> offset = rsvd_head;
> --
> 2.3.6
>
> _______________________________________________
> Nouveau mailing list
> Nouveau@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/nouveau
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
