Re: [PATCH] mm: Drop INT_MAX limit from kvmalloc()

[Kent Overstreet <kent.overstreet@linux.dev>]

On Sun, Oct 20, 2024 at 10:51:10PM +0100, Joshua Ashton wrote:
> 
> 
> On 10/20/24 9:29 PM, Kent Overstreet wrote:
> > On Sun, Oct 20, 2024 at 01:19:42PM -0700, Linus Torvalds wrote:
> > > On Sun, 20 Oct 2024 at 13:10, Kent Overstreet <kent.overstreet@linux.dev> wrote:
> > > > 
> > > > And the INT_MAX check wouldn't catch truncation anyways - it'd only
> > > > catch integer _underflow_, but allocation size calculations pretty much
> > > > as a rule never use subtractions, so I don't think this check was ever
> > > > worth much to begin with.
> > > 
> > > It fixed a real security issue.
> > 
> > Which you quite conveniently aren't naming.
> > 
> > > Enough said, and you're just making shit up to make excuses.
> > > 
> > > Also, you might want to start look at latency numbers in addition to
> > > throughput. If your journal replay needs an *index* that is 2G in
> > > size, you may have other issues.
> > 
> > Latency for journal replay?
> > 
> > No, journal replay is only something happens at mount after an unclean
> > shutdown. We can afford to take some time there, and journal replay
> > performance hasn't been a concern.
> 
> Then why are you arguing about there being an "artificial cap on
> performance", if you can "afford to take some time there"?
> 
> Am I missing something?

The journal keys has to exist as a flat sorted array, and it has to
contain _all_ the (sorted, deduped) keys that were in the journal.