From: Andrew Morton <akpm@linux-foundation.org>
To: Phillip Lougher <phillip@squashfs.org.uk>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] squashfs: harden fragment index table sizing
Date: Sat, 29 Aug 2026 10:52:57 -0700 [thread overview]
Message-ID: <20260829105257.0a9f07041246c1d1e10690cc@linux-foundation.org> (raw)
In-Reply-To: <918464087.420455.1787971711604@eu1.myprofessionalmail.com>
On Sat, 29 Aug 2026 03:48:31 +0100 (BST) Phillip Lougher <phillip@squashfs.org.uk> wrote:
>
> > On 29/08/2026 00:37 BST Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> >
> > Sashiko review of this series claims to have found a whole bunch of
> > similar issues which you may choose to address:
> >
> > https://sashiko.dev/#/patchset/20260822143328.68867-1-kmehltretter@gmail.com
> >
> > I don't know how useful this report will be - the first part seems
> > wrong in lots of ways, as if Sashiko was using an ancient copy of the
> > code. But the things it claims aren't there have been present since
> > 2018.
> >
>
> I have been receiving a lot of AI generated issues similar to these on the
> Squashfs-tools code and the Squashfs kernel code over the last month.
>
> I have not been idle and ignoring them, and I have been spent the last
> couple of weeks fixing them full-time in the Squashfs-tools code, and
> the kernel code.
>
> In the Squashfs-tools code I have reviewed about 20,000 lines of code so
> far, and this has generated over 50 commits. These commits I have
> committed to the Squashfs-tools git-hub repository here
>
> https://github.com/plougher/squashfs-tools
>
> I am also most of the way through reviewing the Squashfs kernel code, it
> is about 70% complete. So far it has generated 12 patches, and there
> will be more. Obviously the kernel patches are queued up for a posting
> next week.
Cool, thanks for the diligence. Lots of projects appear to be in the
same boat at present - hang in there!
> So I am not asleep at the wheel here, I know about them and I am
> addressing them.
I hope it didn't sound like I was implying such a thing!
For a patch series like this: it looks correct enough to me so my
approach is to push it out for external testing and to sit on it
indefinitely until I hear from Maintainer.
prev parent reply other threads:[~2026-08-29 17:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 14:33 Karl Mehltretter
2026-08-22 14:33 ` [PATCH 1/2] squashfs: fix fragment index table sizing overflow on 32-bit Karl Mehltretter
2026-08-22 14:33 ` [PATCH 2/2] squashfs: make the fragment index table bounds check overflow-safe Karl Mehltretter
2026-08-28 23:37 ` [PATCH 0/2] squashfs: harden fragment index table sizing Andrew Morton
2026-08-29 2:48 ` Phillip Lougher
2026-08-29 17:52 ` Andrew Morton [this message]
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=20260829105257.0a9f07041246c1d1e10690cc@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=kmehltretter@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@squashfs.org.uk \
/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®