Re: [PATCH V3] nvme: enable char device per namespace

From: "Javier González" <javier@javigon.com>
To: Keith Busch <kbusch@kernel.org>
Cc: sagi@grimberg.me, linux-nvme@lists.infradead.org,
	linux-block@vger.kernel.org, minwoo.im.dev@gmail.com,
	"Javier González" <javier.gonz@samsung.com>,
	hch@lst.de
Subject: Re: [PATCH V3] nvme: enable char device per namespace
Date: Wed, 16 Dec 2020 09:01:05 +0100	[thread overview]
Message-ID: <84685B9E-B4CB-4F30-AB58-DB88F117889D@javigon.com> (raw)
In-Reply-To: <20201215221254.GA3915989@dhcp-10-100-145-180.wdc.com>

> On 15 Dec 2020, at 23.12, Keith Busch <kbusch@kernel.org> wrote:
> 
> On Tue, Dec 15, 2020 at 08:55:57PM +0100, javier@javigon.com wrote:
>> From: Javier González <javier.gonz@samsung.com>
>> 
>> Create a char device per NVMe namespace. This char device is always
>> initialized, independently of whether the features implemented by the
>> device are supported by the kernel. User-space can therefore always
>> issue IOCTLs to the NVMe driver using the char device.
>> 
>> The char device is presented as /dev/generic-nvmeXcYnZ. This naming
>> scheme follows the convention of the hidden device (nvmeXcYnZ). Support
>> for multipath will follow.
>> 
>> Christoph, Keith: Is this going in the right direction?
> 
> I think this is looking okay, though I'm getting some weird errors and
> warnings during boot. The first one looks like the following (I will
> look into it too, but I wanted to get a reply out sooner).
> 
> [    4.734143] sysfs: cannot create duplicate filename '/dev/char/242:1'
> [    4.736359] CPU: 4 PID: 7 Comm: kworker/u16:0 Not tainted 5.10.0+ #172
> [    4.740836] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> [    4.744228] Workqueue: nvme-wq nvme_scan_work [nvme_core]
> [    4.745558] Call Trace:
> [    4.746122]  dump_stack+0x6d/0x88
> [    4.746834]  sysfs_warn_dup.cold+0x17/0x24
> [    4.747656]  sysfs_do_create_link_sd.isra.0+0xb0/0xc0
> [    4.747659]  device_add+0x604/0x7b0
> [    4.749298]  cdev_device_add+0x46/0x70
> [    4.753241]  ? cdev_init+0x51/0x60
> [    4.753246]  nvme_alloc_ns+0x670/0x8a0 [nvme_core]
> [    4.753249]  ? _cond_resched+0x15/0x30
> [    4.753253]  nvme_validate_or_alloc_ns+0x99/0x190 [nvme_core]
> [    4.753258]  nvme_scan_work+0x152/0x290 [nvme_core]
> [    4.753261]  process_one_work+0x1ac/0x330
> [    4.753262]  worker_thread+0x50/0x3a0
> [    4.753264]  ? process_one_work+0x330/0x330
> [    4.753265]  kthread+0xfb/0x130
> [    4.753266]  ? kthread_park+0x90/0x90
> [    4.753269]  ret_from_fork+0x1f/0x30
> [    4.753272] CPU: 5 PID: 88 Comm: kworker/u16:1 Not tainted 5.10.0+ #172

Mmm. I’ll look into it. I don’t see this in the config I’m using. 

> 
>> Keith: Regarding nvme-cli support, what do you think about reporting the
>> char device as existing block devices? If this is OK with you, I will
>> submit patches for the filters.
> 
> I'm not sure I understand what you mean about reporting these as
> "existing block devices". Are you talking about what's shown in the
> 'nvme list' output?

Exactly. Do we want the char device to be listed?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme