[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20240117124118.6cc05209fba27ab307b0a439@linux-foundation.org>
Date: Wed, 17 Jan 2024 12:41:18 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lstoakes@...il.com>
Cc: Uladzislau Rezki <urezki@...il.com>, Nathan Chancellor
<nathan@...nel.org>, linux-mm@...ck.org, LKML
<linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>, Christoph
Hellwig <hch@...radead.org>, Matthew Wilcox <willy@...radead.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, Dave Chinner
<david@...morbit.com>, Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH 1/1] Fix a wrong value passed to __find_vmap_area()
On Tue, 16 Jan 2024 22:13:17 +0000 Lorenzo Stoakes <lstoakes@...il.com> wrote:
> > There was a type in the vmalloc_dump_obj() function. Instead
> > of passing a real address which is "objp" an "addr" was used
> > what is wrong and not initialized.
> >
> > Reported-by: kernel test robot <lkp@...el.com>
> > Fixes: 86817057732a ("mm: vmalloc: remove global vmap_area_root rb-tree")
>
> I know the commits are likely to get squashed/messed with (this is now
> d1d9bdd672c4 in my mm-unstable tree), will this get corrected in the commit
> message also? Slightly tricky one.
>
> Perhaps a note for Andrew unless his scripts do this already - please
> update this to wherever "mm: vmalloc: remove global vmap_area_root rb-tree"
> lands?
Yep, I'll scrunch together
mm-vmalloc-remove-global-vmap_area_root-rb-tree.patch
mm-vmalloc-remove-global-vmap_area_root-rb-tree-fix.patch
mm-vmalloc-remove-global-vmap_area_root-rb-tree-fix-2.patch
before merging it all into mm-stable and shall tidy up the changelog
trail.
Powered by blists - more mailing lists