Re: [PATCH v3 1/1] mm/memory: constrain generic_access_phys() to page boundary

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 13 Sep 2026 01:28:18 -0700 Yuan Tan <yuant@nebusec.ai> wrote:

> 
> >> +	    (phys_addr != ((resource_size_t)args.pfn << PAGE_SHIFT)) ||
> > hoo boy we've made a mess of the types in there, but I don't see a
> > feasible improvement in the context of this patch.
> >
> > Also, a [0/N] isn't needed or desirable when N==1!  I'll consolidate
> > both into a singleton patch.
> 
> Hi,
> 
> 
> Luxiao is helping us fix some of the bugs found by our bug finding tool.

> 
> 
> Normally, our patch series includes a reproducer in the cover letter, so
> we usually send these patches with a cover letter. I believe Luxiao
> simply forgot to include the reproducer in this version. The reproducer
> for this bug can be found here:
> https://lore.kernel.org/all/cover.1784428532.git.rakukuip@gmail.com/


Great, thanks.

See, what I'm always looking for in bug fixes is a solid description
of the significance/impact/risk which that bug has upon our users. 

This impact ranges between "Impossibly improbable thing which some AI
scan found but which nobody is ever going to hit" through to "this
crashes our entire fleet 12 times per day".

The range really is that broad and this information matters.  And
people care about it.  I look to authors to help us understand and
assess this impact.  So please do whatever you can (organization-wide)
to ensure that this info is made available to its potential audience.


> For future patches, if we are sending a single patch without a cover
> letter, what would be the preferred way to include the reproducer?
> Should we put it directly in the commit message, or place it below the
> --- separator so that the reproducer itself does not become part of the
> permanent git history?


It depends.

Formally, the reproducer should be made part of selftests/, so the bug
can never reappear.  I think that's excessive for this project and the
risk of reintroduction is so low that this isn't worthwhile.

Pasting it in to the formal changelog is reasonable.  Putting it below
the --- is probably better, as long as the permanent changelog mentions
its existence.  Then highly motivated people can follow the Link: and
find the reproducer.

The main value in the reproducer is knowing that it exists!  That this
bug can really be hit from userspace.

> 
> Also, I have been collecting the bug report by llm into a syzbot-like
> tracking system[1].
> The tracker aggregates bug reports from multiple sources, including
> Sashiko, and then attempts to validate the reports and generate
> reproducers to make sure it is not a false positive . It also
> automatically tracks whether a bug has been fixed.


That's a great initiative, thanks.

> 
> For the networking side, I have already imported the Sashiko reports
> into the bug tracker and shared it with the net maintainers. I am
> planning to do the same for mm, but haven't gotten to it yet. There are
> already a few mm bugs in the tracker that were found by our own tool,
> and none of them seem to have security implications.
> 
> If you have a chance, I'd be interested to hear what you think. Any
> suggestions on how to make it more useful for mm maintainers would be
> very welcome.

I saw.  I'd love to spend time with this but you know how it is.  We're
all overwhelmed by the bot invasion at present, and none more than me. 
I view your contributions as "parallelization of effort".  Keep the
fixes coming and I'll do my best to get them through our pipeline and
out to our users.