linux-kernel - Re: [PATCH 5/5 v2] nvme: LightNVM support

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: <alpine.LNX.2.00.1504161433110.32385@localhost.lm.intel.com>
Date:	Thu, 16 Apr 2015 14:55:02 +0000 (UTC)
From:	Keith Busch <keith.busch@...el.com>
To:	Matias Bjørling <m@...rling.me>
cc:	hch@...radead.org, axboe@...com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
	javier@...etta.io, keith.busch@...el.com
Subject: Re: [PATCH 5/5 v2] nvme: LightNVM support

On Wed, 15 Apr 2015, Matias Bjørling wrote:
> @@ -2316,7 +2686,9 @@ static int nvme_dev_add(struct nvme_dev *dev)
> 	struct nvme_id_ctrl *ctrl;
> 	void *mem;
> 	dma_addr_t dma_addr;
> -	int shift = NVME_CAP_MPSMIN(readq(&dev->bar->cap)) + 12;
> +	u64 cap = readq(&dev->bar->cap);
> +	int shift = NVME_CAP_MPSMIN(cap) + 12;
> +	int nvm_cmdset = NVME_CAP_NVM(cap);

The controller capabilities' command sets supported used here is the
right way to key off on support for this new command set, IMHO, but I do
not see in this patch the command set being selected when the controller
is enabled

Also if we're going this route, I think we need to define this reserved
bit in the spec, but I'm not sure how to help with that.

> @@ -2332,6 +2704,7 @@ static int nvme_dev_add(struct nvme_dev *dev)
> 	ctrl = mem;
> 	nn = le32_to_cpup(&ctrl->nn);
> 	dev->oncs = le16_to_cpup(&ctrl->oncs);
> +	dev->oacs = le16_to_cpup(&ctrl->oacs);

I don't find OACS used anywhere in the rest of the patch. I think this
must be left over from v1.

Otherwise it looks pretty good to me, but I think it would be cleaner if
the lightnvm stuff is not mixed in the same file with the standard nvme
command set. We might end up splitting nvme-core in the future anyway
for command sets and transports.