Received-SPF: pass (google.com: domain of linux-kernel+bounces-38502-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <dbb3ad13-7524-4861-8006-b2ea426fbacd@oracle.com>
Date: Thu, 25 Jan 2024 11:28:22 +0000
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 15/15] nvme: Ensure atomic writes will be executed
 atomically
Content-Language: en-US
To: Keith Busch <kbusch@kernel.org>
Cc: axboe@kernel.dk, hch@lst.de, sagi@grimberg.me, jejb@linux.ibm.com,
        martin.petersen@oracle.com, djwong@kernel.org, viro@zeniv.linux.org.uk,
        brauner@kernel.org, dchinner@redhat.com, jack@suse.cz,
        linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-nvme@lists.infradead.org, linux-xfs@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com,
        linux-scsi@vger.kernel.org, ming.lei@redhat.com, ojaswin@linux.ibm.com,
        bvanassche@acm.org, Alan Adamson <alan.adamson@oracle.com>
References: <20240124113841.31824-1-john.g.garry@oracle.com>
 <20240124113841.31824-16-john.g.garry@oracle.com>
 <ZbGwv4uFdJyfKtk5@kbusch-mbp.dhcp.thefacebook.com>
From: John Garry <john.g.garry@oracle.com>
Organization: Oracle Corporation
In-Reply-To: <ZbGwv4uFdJyfKtk5@kbusch-mbp.dhcp.thefacebook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?SkUweFVKMTgxeDZMaktFelhaUjViT09SdGRvbG02UWZMeEJ3N2NjbC9iVlFr?=
 =?utf-8?B?MlpzWEJsdW85dDl2QlNUQmNnNk11blNQZHp3TGxhdDl2a2ZydGR1R0RFS3Y3?=
 =?utf-8?B?cnN2SU91QXQybFZjbVdDNWhIZGZjbzdGWlViOFMrZng2bE5GcEdsOC9McURj?=
 =?utf-8?B?TkZ4VVEzTzBWdkQ3MnBySGprK0NYWmlwcDFRMFJVSlRtbnNjL2xwellCVlBz?=
 =?utf-8?B?OWNCWUV2eDI1NFUyNXRQTU1PNm93bXN2OWJQd3FzN0xvbGJWeHJQNjZnbytV?=
 =?utf-8?B?NHRUYk91akIzbmtqazRuWktlOW1OcnVVa3BQRXYxWkFrMXpCcGcrV0hiTFhF?=
 =?utf-8?B?ZnVEcmx2TFQ4WmV4alJVbTZRYjVjZ21hV1hnWVZLKzEzYTkxLytzZnZLUDFw?=
 =?utf-8?B?UWxRZjFIQlZjUk92eVlMazBhVDRTTWlLYXdxTWNOZk0xYnpENDBsUVdSUnRD?=
 =?utf-8?B?eWJCcDEwWWtmczBvUHdnUm82eU9oWUJsUXBHTVRQQXlJT3ppd1JqL3dkVHd3?=
 =?utf-8?B?UzlMWTZVb1ZTWFJVZWREM0s5REpZTURxNmhRc1VoTmc3aGhMM2pHaTdyWXVr?=
 =?utf-8?B?V0xvTEhBR2V4OStsWGhxUUpPSzVZNUpCc1dOZTljc2EwSmh6cGdQbGJ1YlVJ?=
 =?utf-8?B?UG9LdmVmcjdLM3Bpdld4Rk1Ha3JUaVZMZ1ljcStCTUo5TVdSSmRYVVVnY09J?=
 =?utf-8?B?dHNrQUNocDFRWFkyTnJtSjdpd1NjNXBLK0NiNS9ucndEZGZ4SUdBaGdtTUUr?=
 =?utf-8?B?bnBiOVVOd1J5WDFHZXNpWlZjY1ppUFMxRlN2a0s0ZWQ2MmxUWlh1ai94SFlO?=
 =?utf-8?B?OHVNb2QyUWp0ZVNsY2NJNXNjTDZlc04rRExTbGF2ZzRMVUhWM1paSEpqU2li?=
 =?utf-8?B?UUM3RUdRNUFBTWpqc3lkd2IrZjhXRjFTWTZxcW81Zlk3V3lKM1JxaE9sWHMx?=
 =?utf-8?B?cTB1d1lHait3U3BDTTVCeGJCRHAzWCtjT1ZjRjh3NCsrck1CNHpNWmhPUUg5?=
 =?utf-8?B?MTNZYnJuWHZGS2FjcHVXMDVVdklIR3p4RGFzREo1bmVjVkNvSjFPMnpoUC8y?=
 =?utf-8?B?S0hXWGJQdmUwVUcyUGlLZUlzaUxDQStYajA5aVA4NWVYUWNDUjZZMWhkUGZJ?=
 =?utf-8?B?SkUybmxJY3BQMi9hZlZvMVJaczl6cWJFTWloaG44TjVYamIydkt6eDM3dXE3?=
 =?utf-8?B?dklPcUllemxRYXB5K3FWdXBpN2RWR3Jud1pjbURtVXBlSStHZUtRWmFHSW0r?=
 =?utf-8?B?em5adVJESWxHTHl1YlFSeUd1U3RqTUN0UHFhL2N5OGlERlVkVkJaYTJUWUQ5?=
 =?utf-8?B?eDhwRHpVc1RHWW1wSFpUeDE4czVhV1RkaC8yTzZmK29DVTdMcjlnMi9uMVlu?=
 =?utf-8?B?YldQUk5oSlpsWFdjZ2lxUnpaMll5Rm1Kc2M1Wi90OVRLZ1RZc09QaTdHL2JE?=
 =?utf-8?B?cEliR1ZEb2dwWm9YRWl6UTMzN3cyTHRiQ3VhOFhQUmZsS0syNmFRWk1BZ044?=
 =?utf-8?B?SEhQYXJOdk9CMGpna00vMEdGOFV5UTdQVUpQdEZkOVNnMWRzdzQwQ2lSUHNu?=
 =?utf-8?B?ZVRENDV1M0ZDRk43ZzMwRVVVeEdhYTRpWVRnSzd0d2RhWGh0eUhSSFA3QTVC?=
 =?utf-8?B?c2xwbmlkRmpwbGZoTkdlUjU0L0hUYzNwNW1OeGxudUw2RVYzcDF1ZHZTZm1Z?=
 =?utf-8?B?N1IydmJJS2hNaDB6ZUJyNytpLzhvcEs5dVQ2VjBCUVQ1ejBhQlNPdVA0eDBO?=
 =?utf-8?B?OUFSd1VRVzNqdHE3Y21KdGhUT0ZIYTJNWHd4RHFEVlIyR2czalRiaTE3Vldn?=
 =?utf-8?B?YWlEenoxNUp0Nk5heklsR2hSRWxGWkxwc1R4Z2Fmc0ttWXk4ODd1Q1EzbkJZ?=
 =?utf-8?B?YlRDbmtyaFdFaktoWFJLNDlNSTc0dThrMlBTdnQ0dzZ5UWdJZjJvbkhXbloz?=
 =?utf-8?B?bzcxQURhV0dYdlVCMWJGYnRhTVlkRVpHdythTEdKNnRFTVl1Y290YkxJUFg2?=
 =?utf-8?B?aElCOHRMenVGRDI5TldDWEwvallkQlU1bGVIcG1qMW54NEsraW5YTlhDamo2?=
 =?utf-8?B?WkNORnJnUU1RaHljTWtPUjdPZDRSYTJUWmJiYkhSdXMwSnBoSlJITnBqV0lh?=
 =?utf-8?B?NE0xcDRScXZON1R3VXlrN2RnaTZ6UGs0T1MwN0pzOGk1Y3NMRnJjaUE1OEdX?=
 =?utf-8?B?MlE9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	km8xrar7MaX8dXRhnKNX0qkPqCjhUBGOvvU13F0kKkvS6AU5BzlNCGv/fLnkYtOYbRJr1ZKg0e1Kd8kMhiCiT3Lanipsh0fJZGitdym8YUXrALfgbSjybFP55rYgznIKKXgidRBGU+iitnSr5D4oAveEzv4gkzVY5iLpGvcpCAWjYbRVatMEH2vPvih3zoWl5QawkmMjQ8RnWt0275THeq1j1atI+UPP6WWwhI3bC1bnoK13ImN8L9DU/GfANuwWMjBVHNYNME4TrnnM64sAKZaaliRwp/1+V1dAbAy3IajC4yvi6c4w+CaOr44A+x5pr2b17Q4E8ZtZeJ15/kewAgFsrghVEGK0frMutKccv+W5Hvz1UN4w8F6puARc/kx7CgSYqnIqapuM0ryIlIM7pCoi/CmS3FK63qMSyInB9kA9ee/sf9RsT8ZaSYpgfdNbYHmeCLxz2AngdrBiLCr1VWwyCD1IlPEZsiG4hSGOHUPAVm8RqjZ5s21uyGcJSOaTqP7R+VVtREUamUUCwcXk//DFk25OmVOhuAtK9Q/Yo6bolL+gfO6QneWI/A3hD0hQ6pnca4yCBZUEX8T+pvC09uKenxdKl0jU4YBd3ChCwD0=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 08212471-e8af-4c64-68e4-08dc1d98bff0
X-MS-Exchange-CrossTenant-AuthSource: DM6PR10MB4313.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2024 11:28:27.4602
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: GfTf321zi9u/wGdJFLBY/t5Cc6NCgES0nkofGXBtyyeo4HwgAjKgdvHCJmu06PpqkwhLQNWjdo7V5o3z2TPAZQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR10MB5228
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-01-25_06,2024-01-25_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0
 mlxlogscore=999 mlxscore=0 phishscore=0 adultscore=0 spamscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2311290000 definitions=main-2401250079
X-Proofpoint-ORIG-GUID: Vf1iq_2r6zqSGZHGc0SvAfDZcsgz2DEJ
X-Proofpoint-GUID: Vf1iq_2r6zqSGZHGc0SvAfDZcsgz2DEJ

On 25/01/2024 00:52, Keith Busch wrote:
> On Wed, Jan 24, 2024 at 11:38:41AM +0000, John Garry wrote:
>> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
>> index 5045c84f2516..6a34a5d92088 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -911,6 +911,32 @@ static inline blk_status_t nvme_setup_rw(struct nvme_ns *ns,
>>   	if (req->cmd_flags & REQ_RAHEAD)
>>   		dsmgmt |= NVME_RW_DSM_FREQ_PREFETCH;
>>   
>> +	/*
>> +	 * Ensure that nothing has been sent which cannot be executed
>> +	 * atomically.
>> +	 */
>> +	if (req->cmd_flags & REQ_ATOMIC) {
>> +		struct nvme_ns_head *head = ns->head;
>> +		u32 boundary_bytes = head->atomic_boundary;
>> +
>> +		if (blk_rq_bytes(req) > ns->head->atomic_max)
>> +			return BLK_STS_IOERR;
>> +
>> +		if (boundary_bytes) {
>> +			u32 mask = boundary_bytes - 1, imask = ~mask;
>> +			u32 start = blk_rq_pos(req) << SECTOR_SHIFT;
>> +			u32 end = start + blk_rq_bytes(req);
>> +
>> +			if (blk_rq_bytes(req) > boundary_bytes)
>> +				return BLK_STS_IOERR;
>> +
>> +			if (((start & imask) != (end & imask)) &&
>> +			    (end & mask)) {
>> +				return BLK_STS_IOERR;
>> +			}
>> +		}
>> +	}
> Aren't these new fields, atomic_max and atomic_boundary, duplicates of
> the equivalent queue limits? Let's just use the queue limits instead.

I was making a copy of these limits in the driver out of an abundance of 
caution. I suppose the atomic_max and atomic_boundary values won't be 
modified in the block layer, so I could use them instead.

> 
> And couldn't we generically validate the constraints are not violated in
> submit_bio_noacct() instead of doing that in the low level driver? The
> driver assumes all other requests are already sanity checked, so I don't
> think we should change the responsibility for that just for this flag.

As a safety mechanism, we want to ensure the complete stack is not 
giving us out-of-limits atomic writes.

We have limits checks in XFS iomap and fops.c, but we would also want to 
ensure that the the block layer is not doing anything it shouldn't be 
doing after submit_bio_noacct(), like merging atomic write BIOs which 
straddle a boundary or exceed atomic_max (if there were any merging).

The SCSI standard already has provision for error'ing an atomic write 
command which exceeds the target atomic write capabilities, while NVMe 
doesn't.

BTW, Christoph did mention that he would like to see this:
https://lore.kernel.org/linux-nvme/20231109153603.GA2188@lst.de/

Thanks,
John