mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthias Goergens <matthias.goergens@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Christian Brauner <brauner@kernel.org>,
	Yichong Chen <chenyichong@uniontech.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] isofs: simplify the level 3 directory record walk
Date: Tue, 22 Sep 2026 22:01:35 +0800	[thread overview]
Message-ID: <20260922140137.1768064-1-matthias.goergens@gmail.com> (raw)

You mentioned isofs_read_level3_size() deserves the same treatment as
commit b2eb2e288604, so here it is: validate every record with
isofs_dir_record_valid() first, then drop the straddling-record
reassembly and the scratch buffer it needed.

The one thing to watch is that the code being removed did two jobs.  It
ran on "offset >= bufsize", so as well as reassembling a straddling
record it advanced the block for a record ending exactly at the end of
one.  Only the first job is dead now, so I folded the second into the
zero-length check, the way you did in bda8d8d49ca1 ("isofs: Fix
handling of directories with tight blocks").

I left isofs_read_inode() alone.  Its condition is
"offset + de_len > bufsize", so it only ever reassembled and never did
the block advance.  Cleaning that one up is a separate patch.

Both patches touch only fs/isofs/inode.c, so they apply on top of
bda8d8d49ca1, and they list the same entries on every image I tested.

I ran bda8d8d49ca1 on its own against them too.  Entries listed,
driving fs/isofs from a userspace harness:

  image                                     before  bda8d8d49ca1
  xorrisofs -iso-level 1, 65 files              46            65
  same, one boundary record marked assoc        45            64
  Debian 13.7.0 amd64 DVD-1 (directories)     9340          9460
  Joliet, Rock Ridge + Joliet                    2             2

Tested-by: Matthias Goergens <matthias.goergens@gmail.com>

Unrelated, and only because you are a VFS maintainer.  Two regressions
I have chased this month were introduced by patches sent to
linux-fsdevel without a linux-kernel copy, and linux-fsdevel is not
among the lists Sashiko monitors, so it never saw either of them.
Enabling it for the list was proposed in July and seems to have
stalled.

For what it's worth, I'm in favour of adding Sashiko reviews.  Sashiko
ain't perfect, but I find its signal-to-noise ratio good enough to be a
net positive.  In fact I find it useful enough that I often run it
locally before sending patches out, despite the high token costs.

Matthias Goergens (2):
  isofs: validate directory records in isofs_read_level3_size()
  isofs: drop support for level 3 records straddling blocks

 fs/isofs/inode.c | 44 +++++++++++++-------------------------------
 1 file changed, 13 insertions(+), 31 deletions(-)


base-commit: 40288c9206c17eb66a603262e06a58d300d0f279
-- 
2.55.0


             reply	other threads:[~2026-09-22 14:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22 14:01 Matthias Goergens [this message]
2026-09-22 14:01 ` [PATCH 1/2] isofs: validate directory records in isofs_read_level3_size() Matthias Goergens
2026-09-23 13:37   ` Jan Kara
2026-09-23 15:32     ` Matthias Goergens
2026-09-23 17:01       ` Jan Kara
2026-09-22 14:01 ` [PATCH 2/2] isofs: drop support for level 3 records straddling blocks Matthias Goergens

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=20260922140137.1768064-1-matthias.goergens@gmail.com \
    --to=matthias.goergens@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chenyichong@uniontech.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --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®