All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daan De Meyer <daan.j.demeyer@gmail.com>
To: linux-scsi@vger.kernel.org
Cc: James.Bottomley@HansenPartnership.com,
	martin.petersen@oracle.com, Daan De Meyer <daan@amutable.com>,
	Daan De Meyer <daan.j.demeyer@gmail.com>
Subject: [PATCH] scsi: sr: propagate read-only status to block layer via set_disk_ro()
Date: Mon, 30 Mar 2026 12:21:24 +0000	[thread overview]
Message-ID: <20260330122124.755083-1-daan@amutable.com> (raw)

The sr driver tracks whether a CD-ROM drive supports writing via the
cd->writeable flag, which is determined from the drive's MODE SENSE
capabilities page (page 0x2A). When the drive does not report any write
capabilities (CD-RW, DVD-RAM, MRW-W, etc.), writeable remains 0 and
write requests are rejected in sr_init_command().

However, this information is never propagated to the block layer via
set_disk_ro(). As a result, BLKROGET on a CD-ROM device always returns
0 (writable), even when the drive has no write capabilities and writes
will inevitably fail. This causes problems for userspace that relies on
BLKROGET to determine whether a block device is read-only, for example:

 - systemd's loop device setup uses BLKROGET to decide whether to create
   a loop device with LO_FLAGS_READ_ONLY. Without the read-only flag,
   writes pass through the loop device to the CD-ROM and fail with I/O
   errors.

 - systemd-fsck checks BLKROGET to decide whether to run fsck in
   no-repair mode (-n). Without the read-only flag, fsck attempts writes
   that produce I/O errors.

This is in contrast to the sd driver (SCSI disks), which has called
set_disk_ro() based on the MODE SENSE Write Protect bit since before
the beginning of the git history.

Fix this by calling set_disk_ro(disk, !cd->writeable) in sr_probe()
after get_capabilities() has determined the drive's write support.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Daan De Meyer <daan.j.demeyer@gmail.com>
---
 drivers/scsi/sr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 7adb2573f50d..8ed002f82e36 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -684,6 +684,7 @@ static int sr_probe(struct scsi_device *sdev)
 	sr_vendor_init(cd);
 
 	set_capacity(disk, cd->capacity);
+	set_disk_ro(disk, !cd->writeable);
 	disk->private_data = cd;
 
 	if (register_cdrom(disk, &cd->cdi))
-- 
2.53.0


                 reply	other threads:[~2026-03-30 12:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260330122124.755083-1-daan@amutable.com \
    --to=daan.j.demeyer@gmail.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=daan@amutable.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.