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: <20251231213529.GJ3864520-mkhalfella@purestorage.com>
Date: Wed, 31 Dec 2025 13:35:29 -0800
From: Mohamed Khalfella <mkhalfella@...estorage.com>
To: Sagi Grimberg <sagi@...mberg.me>
Cc: Chaitanya Kulkarni <kch@...dia.com>, Christoph Hellwig <hch@....de>,
	Jens Axboe <axboe@...nel.dk>, Keith Busch <kbusch@...nel.org>,
	Aaron Dailey <adailey@...estorage.com>,
	Randy Jennings <randyj@...estorage.com>,
	John Meneghini <jmeneghi@...hat.com>,
	Hannes Reinecke <hare@...e.de>, linux-nvme@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/14] nvmet: Implement CCR nvme command

On Sat 2025-12-27 11:39:55 +0200, Sagi Grimberg wrote:
> 
> >>> +void nvmet_execute_cross_ctrl_reset(struct nvmet_req *req)
> >>> +{
> >>> +	struct nvmet_ctrl *ictrl, *ctrl = req->sq->ctrl;
> >>> +	struct nvme_command *cmd = req->cmd;
> >>> +	struct nvmet_ccr *ccr, *new_ccr;
> >>> +	int ccr_active, ccr_total;
> >>> +	u16 cntlid, status = 0;
> >>> +
> >>> +	cntlid = le16_to_cpu(cmd->ccr.icid);
> >>> +	if (ctrl->cntlid == cntlid) {
> >>> +		req->error_loc =
> >>> +			offsetof(struct nvme_cross_ctrl_reset_cmd, icid);
> >>> +		status = NVME_SC_INVALID_FIELD | NVME_STATUS_DNR;
> >>> +		goto out;
> >>> +	}
> >>> +
> >>> +	ictrl = nvmet_ctrl_find_get_ccr(ctrl->subsys, ctrl->hostnqn,
> >> What does the 'i' stand for?
> > 'i' stands for impacted controller. Also, if you see sctrl the 's'
> > stands for source controller. These terms are from TP8028.
> 
> Can you perhaps add a comment on this?

Okay, will do that.

> 
> >>> +	new_ccr->ciu = cmd->ccr.ciu;
> >>> +	new_ccr->icid = cntlid;
> >>> +	new_ccr->ctrl = ictrl;
> >>> +	list_add_tail(&new_ccr->entry, &ctrl->ccrs);
> >>> +	mutex_unlock(&ctrl->lock);
> >>> +
> >>> +	nvmet_ctrl_fatal_error(ictrl);
> >> Don't you need to wait for it to complete?
> >> e.g. flush_work(&ictrl->fatal_err_work);
> >>
> >> Or is that done async? will need to look downstream...
> > No, we do not need to wait for ictrl->fatal_err_work to complete. An AEN
> > will be sent when ictrl exits. It is okay if AEN is sent before CCR
> > request is completed. The initiator should expect this behavior and deal
> > with it.
> 
> Yes, saw that in a later patch (didn't get to do a full review yet)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ