On Wed, Jun 29, 2022 at 12:37:59PM -0700, Bart Van Assche wrote: > On 6/29/22 12:05, Kent Overstreet wrote: > > On Wed, Jun 29, 2022 at 11:51:27AM -0700, Bart Van Assche wrote: > > > On 6/29/22 11:40, Kent Overstreet wrote: > > > > But Jens, to be blunt - I know we have different priorities in the way we write code. > > > > > > Please stay professional in your communication and focus on the technical > > > issues instead of on the people involved. > > > > > > BTW, I remember that some time ago I bisected a kernel bug to one of your > > > commits and that you refused to fix the bug introduced by that commit. I had > > > to spend my time on root-causing it and sending a fix upstream. > > > > I'd be genuinely appreciative if you'd refresh my memory on what it was. Because > > yeah, if I did that that was my fuckup and I want to learn from my mistakes. > > I was referring to the following two conversations from May 2018: > * [PATCH] Revert "block: Add warning for bi_next not NULL in bio_endio()" (https://lore.kernel.org/linux-block/20180522235505.20937-1-bart.vanassche@xxxxxxx/) > * [PATCH v2] Revert "block: Add warning for bi_next not NULL in bio_endio()" (https://lore.kernel.org/linux-block/20180619172640.15246-1-bart.vanassche@xxxxxxx/) Oh yeah, that. So, we had - still have - a situation where we have a struct bio field, bi_next, that's used in different ways by different chunks of code, and where that field being left in an indeterminate state when bios are being handed off across module boundaries was likely to be a source of bugs. And having debugged one of those I decided to introduce a check, and then when that broke device mapper (an unfortunate sitation I agree) you decided to just... revert the check I added. Like I said, I would have been happy to fix the device mapper code if I'd been able to get your tests working (did we ever get this added to blk-tests?) - but I wasn't MIA on the list and I would've been happy to work with you on this. Was there something you thought I should've done differently?
