[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZYXNMEXBnuumL3D6@mac.lan>
Date: Sat, 23 Dec 2023 02:53:52 +0900
From: Tejun Heo <tj@...nel.org>
To: Audra Mitchell <aubaker@...hat.com>
Cc: Audra Mitchell <audra@...hat.com>, linux-kernel@...r.kernel.org,
raquini@...hat.com, jiangshanlai@...il.com,
hirokazu.yamauchi.hk@...achi.com,
Laurence Oberman <loberman@...hat.com>,
Donald Douwsma <ddouwsma@...hat.com>
Subject: Re: [PATCH] workqueue.c: Change workqueue to accept variable length
name
Hello,
On Fri, Dec 22, 2023 at 10:35:03AM -0500, Audra Mitchell wrote:
> We have one concrete example from a Hitachi block device driver (notice the
> 47a1/47a2 gets
> cut off with the workqueue name):
>
> Device Workqueue Name (24char zero terminated)
> /dev/sd0279b080047a1 xfs-blockgc/sd0279b0800
> /dev/sd0279b080047a2 xfs-blockgc/sd0279b0800
I see, so it's a combination of somewhat lengthy device names and then xfs
adding a prefix to them. Neither is particularly long but the combination
is.
> I can also imagine this issue being present with nvme devices, but the
> request came from Hitachi.
> I believe it would be up to the device driver to determine if the name can
> be shortened and I've
> included Hitachi requester on this email thread.
>
> Alternatively, we could increase the size of the WQ_NAME_LEN, but it seems
> highly likely we are
> going to butt against the static size again in the future. We previously
> had variable length names
> and it seems (to me) to be the best long term path forward.
Can we just bump the length to 32 and trigger a warning if the requested
name overruns? I want to provide some pressure to limit the length of the
name so that it doesn't get too long over time. If folks bump into it and
can't find a different way to deal with it, we can get bring back the
subject.
Thanks.
--
tejun
Powered by blists - more mailing lists