Received-SPF: pass (google.com: domain of linux-kernel+bounces-178410-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 14 May 2024 14:40:09 +0700
From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Kuan-Wei Chiu <visitorckw@gmail.com>,
	Matthew Mirvish <matthew@mm12.xyz>
Cc: Kent Overstreet <kent.overstreet@linux.dev>, Coly Li <colyli@suse.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: manual merge of the refactor-heap tree with the
 block tree
Message-ID: <ZkMVWeGUb8OSiC4U@archie.me>
References: <20240509152745.08af752f@canb.auug.org.au>
 <te64v6zwwor6jkco6uiu2zz7ern6ijhyu5okfvdz3bmj3w5qfp@mx4zdniwymqj>
 <Zj1RzZdtfL7UQax1@visitorckw-System-Product-Name>
 <buehluxvo234sj7onzl6wwjmuslmnkh7g6vnpru23kpti6qmpp@7nqak2ser7mw>
 <Zj2PX6Fy3BEnQc50@visitorckw-System-Product-Name>
 <20240510034618.GA3161190@mm12.xyz>
 <Zj3kowGa9XzJ0yak@visitorckw-System-Product-Name>
 <Zj/F/yf0ixB/eRX7@visitorckw-System-Product-Name>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="312VrB8j4PQGMpon"
Content-Disposition: inline
In-Reply-To: <Zj/F/yf0ixB/eRX7@visitorckw-System-Product-Name>


--312VrB8j4PQGMpon
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, May 12, 2024 at 03:24:47AM +0800, Kuan-Wei Chiu wrote:
> On Fri, May 10, 2024 at 05:11:02PM +0800, Kuan-Wei Chiu wrote:
> > On Thu, May 09, 2024 at 11:46:18PM -0400, Matthew Mirvish wrote:
> > > On Fri, May 10, 2024 at 11:07:11AM +0800, Kuan-Wei Chiu wrote:
> > > > On Thu, May 09, 2024 at 07:16:31PM -0400, Kent Overstreet wrote:
> > > > > On Fri, May 10, 2024 at 06:44:29AM +0800, Kuan-Wei Chiu wrote:
> > > > > > On Thu, May 09, 2024 at 03:58:57PM -0400, Kent Overstreet wrote:
> > > > > > > On Thu, May 09, 2024 at 03:27:45PM +1000, Stephen Rothwell wr=
ote:
> > > > > > > > Hi all,
> > > > > > > >=20
> > > > > > > > Today's linux-next merge of the refactor-heap tree got conf=
licts in:
> > > > > > > >=20
> > > > > > > >   drivers/md/bcache/bset.c
> > > > > > > >   drivers/md/bcache/bset.h
> > > > > > > >   drivers/md/bcache/btree.c
> > > > > > > >   drivers/md/bcache/writeback.c
> > > > > > > >=20
> > > > > > > > between commit:
> > > > > > > >=20
> > > > > > > >   3a861560ccb3 ("bcache: fix variable length array abuse in=
 btree_iter")
> > > > > > > >=20
> > > > > > > > from the block tree and commit:
> > > > > > > >=20
> > > > > > > >   afa5721abaaa ("bcache: Remove heap-related macros and swi=
tch to generic min_heap")
> > > > > > > >=20
> > > > > > > > from the refactor-heap tree.
> > > > > > > >=20
> > > > > > > > Ok, these conflicts are too extensive, so I am dropping the=
 refactor-heap
> > > > > > > > tree for today.  I suggest you all get together and sort so=
mething out.
> > > > > > >=20
> > > > > > > Coli and Kuan, you guys will need to get this sorted out quic=
k if we
> > > > > > > want refactor-heap to make the merge window
> > > > > >=20
> > > > > > Hi Coli and Kent,
> > > > > >=20
> > > > > > If I understand correctly, the reported bug is because we attem=
pted to
> > > > > > point (heap)->data to a dynamically allocated memory , but at t=
hat time
> > > > > > (heap)->data was not a regular pointer but a fixed size array w=
ith a
> > > > > > length of MAX_BSETS.
> > > > > >=20
> > > > > > In my refactor heap patch series, I introduced a preallocated a=
rray and
> > > > > > decided in min_heap_init() whether the data pointer should poin=
t to an
> > > > > > incoming pointer or to the preallocated array. Therefore, I am
> > > > > > wondering if my patch might have unintentionally fixed this bug?
> > > > > >=20
> > > > > > I am unsure how to reproduce the reported issue. Could you assi=
st me in
> > > > > > verifying whether my assumption is correct?
> > > > >=20
> > > > > This is a merge conflict, not a runtime. Can you rebase onto Coli=
's
> > > > > tree? We'll have to retest.
> > > >=20
> > > > Oh, sorry for the misunderstanding I caused. When I mentioned "bug"=
 [1]
> > > > earlier, I was referring to the bug addressed in
> > > > 3a861560ccb3 ("bcache: fix variable length array abuse in btree_ite=
r"),
> > > > not a merge conflict.
> > > >=20
> > > > Here are the results after the rebase:
> > > > https://github.com/visitorckw/linux.git refactor-heap
> > > >=20
> > > > [1]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2039368
> > >=20
> > > The ubuntu kernels build with UBSAN now, and the bug reported is just=
 a
> > > UBSAN warning. The original implementation's iterator has a fixed size
> > > sets array that is indexed out of bounds when the iterator is allocat=
ed
> > > on the heap with more space -- the patch restructures it a bit to hav=
e a
> > > single iterator type with a flexible array and then a larger "stack"
> > > type which embeds the iterator along with the preallocated region.
> > >=20
> > > I took a brief look at the refactor-heap branch but I'm not entirely
> > > sure what's going on with the new min heaps: in the one place where t=
he
> > > larger iterators are used (in bch_btree_node_read_done) it doesn't lo=
ok
> > > like the heap is ever initialized (perhaps since the old iter_init
> > > wasn't used here because of the special case it got missed in the
> > > refactor?) With the new heaps it should be fairly easy to fix though;
> > > just change the fill_iter mempool to be allocating only the minheap d=
ata
> > > arrays and setup iter->heap.data properly with that instead.
> >=20
> > Thank you, Matthew.
> > Not initializing the heap's data pointer was indeed my mistake.
> > Following your advice, I made the following modifications to the code
> > on the refactor-heap branch in my github repo. I hope this time it
> > works well.
> >
> Should I resend it as a patch series?

Go ahead.

--=20
An old man doll... just what I always wanted! - Clara

--312VrB8j4PQGMpon
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZkMVVAAKCRD2uYlJVVFO
o4xpAQDcKGhTrKxpV8NOk9uCQIEYfiixEwNAetO//zNDgyWC3wD/SacWmXhwC6uq
YKUG0mVu0I+GIuX7vPUQfOQsSAyfZQ8=
=vAUY
-----END PGP SIGNATURE-----

--312VrB8j4PQGMpon--