linux-kernel - Re: [PATCH] drm/sched: Use struct for drm_sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5ISGlkBeSHaAqVm@pollux.localdomain>
Date: Thu, 23 Jan 2025 10:55:38 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: phasta@...nel.org
Cc: Boris Brezillon <boris.brezillon@...labora.com>,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	Xinhui Pan <Xinhui.Pan@....com>, David Airlie <airlied@...il.com>,
	Simona Vetter <simona@...ll.ch>,
	Lucas Stach <l.stach@...gutronix.de>,
	Russell King <linux+etnaviv@...linux.org.uk>,
	Christian Gmeiner <christian.gmeiner@...il.com>,
	Frank Binns <frank.binns@...tec.com>,
	Matt Coster <matt.coster@...tec.com>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Qiang Yu <yuq825@...il.com>, Rob Clark <robdclark@...il.com>,
	Sean Paul <sean@...rly.run>, Konrad Dybcio <konradybcio@...nel.org>,
	Abhinav Kumar <quic_abhinavk@...cinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
	Marijn Suijten <marijn.suijten@...ainline.org>,
	Karol Herbst <kherbst@...hat.com>, Lyude Paul <lyude@...hat.com>,
	Rob Herring <robh@...nel.org>, Steven Price <steven.price@....com>,
	Liviu Dudau <liviu.dudau@....com>,
	Luben Tuikov <ltuikov89@...il.com>,
	Matthew Brost <matthew.brost@...el.com>,
	Melissa Wen <mwen@...lia.com>,
	Maíra Canal <mcanal@...lia.com>,
	Lucas De Marchi <lucas.demarchi@...el.com>,
	Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@...el.com>,
	Sunil Khatri <sunil.khatri@....com>,
	Lijo Lazar <lijo.lazar@....com>,
	Mario Limonciello <mario.limonciello@....com>,
	Ma Jun <Jun.Ma2@....com>, Yunxiang Li <Yunxiang.Li@....com>,
	amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org, etnaviv@...ts.freedesktop.org,
	lima@...ts.freedesktop.org, linux-arm-msm@...r.kernel.org,
	freedreno@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
	intel-xe@...ts.freedesktop.org
Subject: Re: [PATCH] drm/sched: Use struct for drm_sched_init() params

On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote:
> On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> > On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > > Philipp Stanner <phasta@...nel.org> wrote:
> > > > 
> > > > >  int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > > > -    const struct drm_sched_backend_ops *ops,
> > > > > -    struct workqueue_struct *submit_wq,
> > > > > -    u32 num_rqs, u32 credit_limit, unsigned int hang_limit,
> > > > > -    long timeout, struct workqueue_struct *timeout_wq,
> > > > > -    atomic_t *score, const char *name, struct device *dev);
> > > > > + const struct drm_sched_init_params *params);
> > > > 
> > > > 
> > > > Another nit: indenting is messed up here.
> > > 
> > > That was done on purpose.
> > 
> > Let's not change this convention, it's used all over the kernel tree,
> > including
> > the GPU scheduler. People are used to read code that is formatted
> > this way, plus
> > the attempt of changing it will make code formatting inconsistent.
> 
> Both the tree and this file are already inconsistent in regards to
> this.

That's not really a good argument to make it more inconsistent, is it?

> 
> Anyways, what is your proposed solution to ridiculous nonsense like
> this?
> 
> https://elixir.bootlin.com/linux/v6.13-rc3/source/drivers/gpu/drm/scheduler/sched_main.c#L1296

I don't think this one needs a solution.

The kernel picked a convention long ago, which also has downsides. If it gets
too bad, we can deviate from conventions at any point of time; for the thing
that otherwise would be bad, but we shouldn't do it in general.