From: Felix Busch <felixbusch470@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Fwd: Re: [PATCH v2 1/2] [PATCH] cdrom: extra upper bound check for logical block address.
Date: Fri, 27 Feb 2026 19:30:30 +0100 [thread overview]
Message-ID: <aaHilnVGlx8Uqx9x@LaptopFB> (raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: Type: message/rfc822, Size: 8615 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 3545 bytes --]
Hi,
sorry for this confusion.
I somehow had in mind while reading this spec that when the capacity of the
disk
is a multiple of the block size, then the sector size would also be a
multiple
of the block size, which is of course not true. Then, of course this needs
to
have a bit more of searching.
Regards
Felix
Am Do., 26. Feb. 2026 um 21:28 Uhr schrieb Phillip Potter <
phil@philpotter.co.uk>:
> On Tue, Feb 24, 2026 at 05:16:12PM +0100, Felix Busch wrote:
> > Hi Phillip,
> >
> > Thank you for your feedback. I’ve updated everything based on your
> suggestions and hope
> > I’ve covered them all.
> >
> > It has been built and run and tested in the following:
> >
> > 1) This has been tested on a real CD-ROM with 700MB capacity, containing
> 2097151
> > sectors in my case. Since 2097151 is not divisible by a blocksize of
> 2048, the if condition is not satisfied.
> >
> > 2) When using a smaller emulated CD-ROM with QEMU with the same
> blocksize,
> > the if condition is triggered when having a too big logical block
> addresses. For example, this occurs when minutes,
> > seconds, and frames are set to UINT8_MAX via an ioctl call.
> >
> > According to this SCSI-2 spec, chapter 14 on this web page (date
> 23.2.2026):
> > https://www.staff.uni-mainz.de/tacke/scsi/SCSI2-introduction.html
> >
> > They are stating:
> > "
> > Logical addressing of CD-ROM information may use any logical block
> length. When the specified logical block
> > length is an exact divisor or integral multiple of the selected number
> of bytes per CD-ROM sector,
> > the device shall map (one to one) the bytes transferred from CD-ROM
> sectors to the bytes of logical blocks.
> > For instance, if 2 048 bytes are transferred from each CD-ROM sector
> (specified by the CD-ROM density code value),
> > and the logical block length is 512 bytes, then each CD-ROM sector shall
> map to exactly four logical blocks.
> > This International Standard does not define the mapping of logical block
> lengths which do not evenly divide
> > or are not exact multiples of the selected number of bytes per CD-ROM
> sector.
> > "
> >
> > So, I do refer to this SCSI-2 spec.
> > Using this information it's possible to use logical_blocks =
> cd_nr_sectors / blocksize to get the number of blocks that are be able to
> read due to this mapping.
> > For now, I decided using this special checking only, due to the given
> statement in the SCSI-2 spec.
> >
> > If lba > blocksize * (logical_blocks - 1), then it should not be
> possible to continue reading a full block, because then, as I understand,
> > it would "overflow" the region it can read from the disk.
> >
>
> I've seen your V3 - please make sure the relevant mailing list is copied
> in when posting patches, as development is ideally done in the open. As
> for that and for this version, I'm sorry but I'm still not convinced of
> the approach unless I'm missing something.
>
> You are taking units of two different things and dividing one by the
> other. Dividing the number of sectors (2,097,151) by the detected
> blocksize (2048 bytes) is not meaningful. The statement in the SCSI-2
> spec simply refers to the difference between CD-ROM sector size in bytes
> and the logical block size in bytes.
>
> Here, you are dividing one thing (number of sectors) by another (block
> size). Do you see what I mean?
>
> Finally, please make sure cover letters of a patch series are labels
> PATCH 0.
>
> Regards,
> Phil
>
[-- Attachment #2.1.2: Type: text/html, Size: 4190 bytes --]
reply other threads:[~2026-02-27 18:31 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=aaHilnVGlx8Uqx9x@LaptopFB \
--to=felixbusch470@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®