From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A09203D9690 for ; Mon, 1 Jun 2026 15:11:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780326723; cv=none; b=e/4I8IdIU55JucxauwCp2Ee7wXHNDQtcZGhtKxidIAcYayuGK1iaUabE1icU5DRX6PTDvFYMh3kKKYoO0YHsbWwuRD7mvoyB6ypd4ecDqNqmrVA6zfIzC5Zh3C2Qu/xr66TvVWaTjqT2v7dyRTFjUmULRlFdF8zopbvUhfbx6ao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780326723; c=relaxed/simple; bh=rWpsWUuAyGs/DUr8UlR/ATk7uflqDoWzL2uxm0n2Mjk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Hu3LADuFEIYhZoghJ7kIG3/TpasnhPMW/vb3yLSvwNVDxH8W0VAgSXXhck8wcqS0Ur7yZ8FPeEawvOMmzLAKAR2g0pnIWjeYQyYVI9PLGHTHdwCUij6G5cLDor2Igh94iVHkALNLcnFcCxNXIcSVrZ/L/h+0JeaO5AHHKX2UNgA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FvCz7+ji; arc=none smtp.client-ip=209.85.210.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FvCz7+ji" Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-7e6b554044fso1221462a34.0 for ; Mon, 01 Jun 2026 08:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780326718; x=1780931518; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BjUlIwGeEm+vNl4Jvgu18HLK73C6LBKofUsrM8OMYNc=; b=FvCz7+jiWMsNpKIe1biGsRCtMda3FAwj7FMGwdv2TvtA+okzJM2aSAkadNEkgOJZQE 3iLB/xpynOMOovZ/TwI8f/hM6N0AW4DA7XUlJPRoZBR3xpUn+lDdNGUi7oRQ6n9vM2IO KgA8KjjuaOxcNBC+2m1BT+wQn6UFqTIZawkznOIao3STsFf4164OsOGJj7j8jyo2b1WL l5b/AWd3Xl9V3I4w9utZJHvCthLgESJdjAEfToajqWLu+4L7W0RDFm/eBXukBctk6/1C S78nRDCt6j+1Zf5y+5qcTq4KKhNulFULST9SDoq4Ua0+mfRB7pxt10pywPYyo3hUSVet l/5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780326718; x=1780931518; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BjUlIwGeEm+vNl4Jvgu18HLK73C6LBKofUsrM8OMYNc=; b=qv2a0rfi1F5VaDvQp8Wij+HhW23jj7uf3wJ86wKQtdbSS3jLPxvGUNl9e/5sXzoQwN YYMlI7j/GTIvnDz4BQBO3aJ1rQeaZNwUnR546i11v3wDaXQQiMehFnrB34THpdDyGuin j7U/fEjAQK7gedO/vLpPHVKiHDRG1iL1c6rCwNVVGz+4OtVw0QP0LwTvUJLK0DOJcPWs bvbvbYKKSEyUgiWF5HukgvdFOPIDFr4yIaIh5GC/TEUC4VpMLtjxE7IojZTt55rWxumY ICUR5A9nv9wMDC7zFrxKaIdkdejfnhDe2sOcWHShmTmTBczlLXkDLE5h8AkVnpvcyOYE AYEw== X-Forwarded-Encrypted: i=1; AFNElJ/kFzTBFzPD3M/4Sz8ZaXmUYZ9zKYnSpmWe3BaPCG+W1vMqv+smi8ubkyIzAriR3DZT7P97ezrgfmlsIYs=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4wJG/BLgBlaQy9Naql5iI72r+qrW+XOwiLNkTB2l4SswAOvKS WUmPZwFyaI1/9ER7oYnI89GgrPv+wF+BeXLDqvormzk2hUBZPzGi4Hpn X-Gm-Gg: Acq92OHRj6ooihPKr8tJA4vR/IEJUllScr8ficTVGO8uDaBBjiZ9TorDdMU/3ZcKtrk H4jCGb89RuSaUHW65QlkNVE5vGOJ2pQ0m8S5tH3QYLFwNBjJIwncoVsG8ikmzXkbhkrNovp1fbn Cadx3CZHn8NIpmWsySBOB6pqq/lAMOZ5UfVOiWG3hEGyVYQm6NQYXVLWPPnCc65uW0sBZ8YIBeE JwGICRhzVy/fVyH7uTbrGdoh0pSOC5DmmYjmLtR3Mb+ynn/0B31VvG0OJTQZc4X7Jh/7b9oiEci 2O5P4ulEFY2KIim5Awhh/OMPbcPUqgLNH0LBXIQ3NJXyKZJ/AgyklV5y33hBqQ5Dhr+q28j3I/9 yCxXGag08IUs8CEhRk6BZ7y6UW7Rskn0bBkOe0tWbhWzr9OpzFGGM4P86Fj9513ADTEFhkCizwH YdftMN7l627/MeeWy+4Qi0bNfgI0EaB0+vgXmLSNlIqeCgLG6lNoxyNk/hjZKqmZtBqxPig1pse xQXhXEZenvmYk/kRDWIZdE= X-Received: by 2002:a05:6830:6732:b0:7e5:68ca:892a with SMTP id 46e09a7af769-7e6a1e76b30mr6788062a34.20.1780326718364; Mon, 01 Jun 2026 08:11:58 -0700 (PDT) Received: from ?IPV6:2605:a601:aab9:5000:242b:bfa1:6aa7:4d01? ([2605:a601:aab9:5000:242b:bfa1:6aa7:4d01]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7e695d4726dsm7671373a34.19.2026.06.01.08.11.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Jun 2026 08:11:57 -0700 (PDT) Message-ID: <0a34e748-15ea-4bca-92a1-e42af023f111@gmail.com> Date: Mon, 1 Jun 2026 10:11:55 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] scsi: target: Allow FUA if no write cache enabled To: "Martin K. Petersen" Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260428203938.9738-1-stuart.w.hayes@gmail.com> Content-Language: en-US From: stuart hayes In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/30/2026 10:43 AM, Martin K. Petersen wrote: > > Stuart, > >> Without this patch, accesses with FUA set will be rejected, even >> though they always go directly to the media when there's no write >> cache. > > The spec allows this. However, ... > >> This is needed because EDK2 FAT filesystem code sets the FUA bit when >> writing, regardless of whether the device advertises support of >> DPOFUA. > > ^^^ that is clearly a spec violation. What is being done to address this > issue? > I've gone through SBC and SPC, and I can't find anything that would suggest that this is a spec violation. And, not that what I think makes any difference, but I don't see the point in requiring an initiator to check DPOFUA before setting FUA on a write that needs to go straight to media... why not just set FUA whenever needed, and if the FUA bit wasn't strictly required to ensure that the write went straight to media, who cares, if the requested behavior is still provided? > Also, wrt. the patch itself, please see: > > https://sashiko.dev/#/patchset/20260428203938.9738-1-stuart.w.hayes%40gmail.com > The AI review suggests moving this fix to sbc_check_dpofua(), so that DPOFUA behavior in the mode page is unchanged, and it just silently allows writes with FUA set even if DPOFUA isn't set. If there's no objection, I'll submit a new patch that does that. The reason I didn't do that the first time around is that it breaks some of the blktests that specifically check to make sure a command fails if FUA is set when DPOFUA isn't.