Received: by 2002:ab2:6857:0:b0:1ef:ffd0:ce49 with SMTP id l23csp2741037lqp; Mon, 25 Mar 2024 08:03:08 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVs05N+O2bnNd3IyLAoPWa3NZq7jyXxgC2di7hlvDKmIyS4wxvby76iKZN+o6ndOFD23VU8nyv0/hX9j0k0VZ2PHPKRAUT2eqTyJnwD8w== X-Google-Smtp-Source: AGHT+IHLie+UKaSWM7KF+c8M6ItwKaUwHd0MtWgf585Oyrt5fEj/bXsZzxKU96SFMqBLmIZDnQyQ X-Received: by 2002:a50:9fcf:0:b0:566:72b0:286a with SMTP id c73-20020a509fcf000000b0056672b0286amr6644424edf.2.1711378987668; Mon, 25 Mar 2024 08:03:07 -0700 (PDT) Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id ev21-20020a056402541500b0056bea096a35si2580745edb.42.2024.03.25.08.03.07 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 08:03:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-116971-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@collabora.com header.s=mail header.b=rhSNa67c; arc=fail (body hash mismatch); spf=pass (google.com: domain of linux-kernel+bounces-116971-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-116971-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=collabora.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 57C3C1F2C5CF for ; Mon, 25 Mar 2024 15:03:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 10F2615B96A; Mon, 25 Mar 2024 12:11:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="rhSNa67c" Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B50B71494CE for ; Mon, 25 Mar 2024 12:05:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711368349; cv=none; b=hGn5vPybATnEa0K551ZoFidrd/6yyMNmAf2XG4K9KtNfuQO5kRbD+GJtMUri9tVjWCVv/4hNnIyrGvwQOEVA9/qoHEX0O5AxD02ZPSgXSh2Hy1anojAboYiqQjMwIzFfX1UNDtaP7CtTNNUWvqVesSxxocFfptT+uUmNWbDAvGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711368349; c=relaxed/simple; bh=K01HEaDiD6y1aoBKX9TsqwEwflbrBF563ZiJ+fzSf1s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YmE/aXwGMbLp1D2Sla5ItcWcoTvvNOVNN9o8ie7HpH3FwwsFCDgKJ6XHBrvaEbgIZOVMd+2FfDD32EXsYmJYqew1aSlQRcZhXHjprdCAJePJZrRN6STWUu2FaExoPRMfIKShhO/W7bzs8S3TKEYunfviz/K/RNQscvG8N9ulas0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=rhSNa67c; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1711368345; bh=K01HEaDiD6y1aoBKX9TsqwEwflbrBF563ZiJ+fzSf1s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=rhSNa67csI0mPPwX/4g3NyykECU8II2r1+naDpHR7BQVzkce2jYvrUFWZ7pFpuKbK /sFbItgVLs7VQytozZFk74g2TBJFGKUrxQfqVQhUH2jEPc47KahVLzPOmyhljYxqX1 XBh2wx5MCwNJiUBW7g7zwa6Lkq57cQdqsntMyiO2Tu8p9fzAFsrzpWEzFjqiP4+yYg kxZKWglUPo5DNCJW2IHPrLlK6nze4zvUPbtqC7CAwiEAFdtA14gWtHmG7xJO0RPKjd IGnBkExocibkm7+ltgH/L7CLTMah1x+Wx+m6jj0MOQbTQnyYd6IwQNr9UT3EddQK3N Y2RhdhEqBdkvQ== Received: from eldfell (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: pq) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 0CF603780626; Mon, 25 Mar 2024 12:05:44 +0000 (UTC) Date: Mon, 25 Mar 2024 14:05:42 +0200 From: Pekka Paalanen To: Louis Chauvet Cc: Rodrigo Siqueira , Melissa Wen , =?UTF-8?B?TWHDrXJh?= Canal , Haneen Mohammed , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , arthurgrillo@riseup.net, Jonathan Corbet , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, jeremie.dautheribes@bootlin.com, miquel.raynal@bootlin.com, thomas.petazzoni@bootlin.com, seanpaul@google.com, marcheu@google.com, nicolejadeyee@google.com Subject: Re: [PATCH v5 05/16] drm/vkms: Add dummy pixel_read/pixel_write callbacks to avoid NULL pointers Message-ID: <20240325140542.4fffd42c.pekka.paalanen@collabora.com> In-Reply-To: <20240313-yuv-v5-5-e610cbd03f52@bootlin.com> References: <20240313-yuv-v5-0-e610cbd03f52@bootlin.com> <20240313-yuv-v5-5-e610cbd03f52@bootlin.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/ssviaODNke6a3Au+epasMDK"; protocol="application/pgp-signature"; micalg=pgp-sha256 --Sig_/ssviaODNke6a3Au+epasMDK Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 13 Mar 2024 18:44:59 +0100 Louis Chauvet wrote: > Introduce two callbacks which does nothing. They are used in replacement > of NULL and it avoid kernel OOPS if this NULL is called. >=20 > If those callback are used, it means that there is a mismatch between > what formats are announced by atomic_check and what is realy supported by > atomic_update. >=20 > Signed-off-by: Louis Chauvet > --- > drivers/gpu/drm/vkms/vkms_formats.c | 43 +++++++++++++++++++++++++++++++= ------ > 1 file changed, 37 insertions(+), 6 deletions(-) >=20 > diff --git a/drivers/gpu/drm/vkms/vkms_formats.c b/drivers/gpu/drm/vkms/v= kms_formats.c > index 55a4365d21a4..b57d85b8b935 100644 > --- a/drivers/gpu/drm/vkms/vkms_formats.c > +++ b/drivers/gpu/drm/vkms/vkms_formats.c > @@ -136,6 +136,21 @@ static void RGB565_to_argb_u16(u8 *in_pixel, struct = pixel_argb_u16 *out_pixel) > out_pixel->b =3D drm_fixp2int_round(drm_fixp_mul(fp_b, fp_rb_ratio)); > } > =20 > +/** > + * black_to_argb_u16() - pixel_read callback which always read black > + * > + * This callback is used when an invalid format is requested for plane r= eading. > + * It is used to avoid null pointer to be used as a function. In theory,= this function should > + * never be called, except if you found a bug in the driver/DRM core. > + */ > +static void black_to_argb_u16(u8 *in_pixel, struct pixel_argb_u16 *out_p= ixel) > +{ > + out_pixel->a =3D (u16)0xFFFF; > + out_pixel->r =3D 0; > + out_pixel->g =3D 0; > + out_pixel->b =3D 0; > +} > + > /** > * vkms_compose_row - compose a single row of a plane > * @stage_buffer: output line with the composed pixels > @@ -238,6 +253,16 @@ static void argb_u16_to_RGB565(u8 *out_pixel, struct= pixel_argb_u16 *in_pixel) > *pixel =3D cpu_to_le16(r << 11 | g << 5 | b); > } > =20 > +/** > + * argb_u16_to_nothing() - pixel_write callback with no effect > + * > + * This callback is used when an invalid format is requested for writeba= ck. > + * It is used to avoid null pointer to be used as a function. In theory,= this should never > + * happen, except if there is a bug in the driver > + */ > +static void argb_u16_to_nothing(u8 *out_pixel, struct pixel_argb_u16 *in= _pixel) > +{} > + > /** > * Generic loop for all supported writeback format. It is executed just = after the blending to > * write a line in the writeback buffer. > @@ -261,8 +286,8 @@ void vkms_writeback_row(struct vkms_writeback_job *wb, > =20 > /** > * Retrieve the correct read_pixel function for a specific format. > - * The returned pointer is NULL for unsupported pixel formats. The calle= r must ensure that the > - * pointer is valid before using it in a vkms_plane_state. > + * If the format is not supported by VKMS a warn is emitted and a dummy = "always read black" > + * function is returned. > * > * @format: DRM_FORMAT_* value for which to obtain a conversion function= (see [drm_fourcc.h]) > */ > @@ -285,18 +310,21 @@ pixel_read_t get_pixel_read_function(u32 format) > * format must: > * - Be listed in vkms_formats in vkms_plane.c > * - Have a pixel_read callback defined here > + * > + * To avoid kernel crash, a dummy "always read black" function is used= It means > + * that during the composition, this plane will always be black. > */ > WARN(true, > "Pixel format %p4cc is not supported by VKMS planes. This is a ke= rnel bug, atomic check must forbid this configuration.\n", > &format); > - return (pixel_read_t)NULL; > + return &black_to_argb_u16; Hi Louis, I'm perhaps a bit paranoid in these things, but I'd make this not black. Maybe something more "screaming" like magenta. There is a slight chance that black might sometimes be expected, or not affect the result. After all, blending something into black with pre-multiplied alpha is equivalent to no-blending (a copy). The kernel warning is good, the magenta is more like an assurance. Anyway, Acked-by: Pekka Paalanen Thanks, pq > } > } > =20 > /** > * Retrieve the correct write_pixel function for a specific format. > - * The returned pointer is NULL for unsupported pixel formats. The calle= r must ensure that the > - * pointer is valid before using it in a vkms_writeback_job. > + * If the format is not supported by VKMS a warn is emitted and a dummy = "don't do anything" > + * function is returned. > * > * @format: DRM_FORMAT_* value for which to obtain a conversion function= (see [drm_fourcc.h]) > */ > @@ -319,10 +347,13 @@ pixel_write_t get_pixel_write_function(u32 format) > * format must: > * - Be listed in vkms_wb_formats in vkms_writeback.c > * - Have a pixel_write callback defined here > + * > + * To avoid kernel crash, a dummy "don't do anything" function is used= It means > + * that the resulting writeback buffer is not composed and can contain= s any values. > */ > WARN(true, > "Pixel format %p4cc is not supported by VKMS writeback. This is a= kernel bug, atomic check must forbid this configuration.\n", > &format); > - return (pixel_write_t)NULL; > + return &argb_u16_to_nothing; > } > } >=20 --Sig_/ssviaODNke6a3Au+epasMDK Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmYBaJYACgkQI1/ltBGq qqeDkw//UGRx7bDK7LJ8EIpMD1eeu9Yl5fhc4WGSlgQMaey7PnjOV+4ic3YISi18 /N4tpm1VnFQYsRPCtemovzRJXfNQ5l/6P7/fum1IWdNw3yQoSpmZVUQV09K7N8S9 eQAKNzJd9Y7D/10amqkPzvP57yKMfYRAqsuhGI1R7VCKj0//QyUG5NzLyvktRX/3 z2Rz7oT2rDR0PzdtTqkPitFLcl6YScDWaJszBBfAtbOLuzZ5cs0DdIczaDQEUggK LgizCbDmVuCf1AW0RdM44c2Z7+3BkAxAKsb6AkrFzsAjbGG0mZ13liHIa2GB3Vwz 6aG9MHpLxXnffFzu8HjpqavupR49lJoxdQ7xpxndkET4aRZIYWMLBKCkAFBjyFsM sOeTcdXYRTylRiBXK2jRfdkJVKsfCaJVFIFerdsg6NAXvvlzoP5sXa5nELvo/GjH 0CJVlbWpkvg4Ow5SblHT92yIWGeoF1jv+RkxB8klcJJTlDLZElbiez/xoDDEAQoj hlnRuClbXts5SEmBbF8kfqqmQF2SjC5nFVZhIpOxqgSpiiFa8yBIYs6XVrpqgZFs fdAv4eQkDMBakKD2J3BajmtkYDrqWXJWFgYGBJJm7BTs1qSbLRb/624EcsWD75c8 KczZPLIwGrrgFFrzxy57/htqt9b+St67N9uqGyikTjTfZCPOrcI= =B4v2 -----END PGP SIGNATURE----- --Sig_/ssviaODNke6a3Au+epasMDK--