Re: [PATCH] Revert "iommu/arm-smmu: Convert to domain_alloc_paging()"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Jason,

On Tue, Feb 13, 2024 at 09:47:26AM -0400, Jason Gunthorpe wrote:
> On Tue, Feb 13, 2024 at 12:59:52PM +0000, Will Deacon wrote:
> > > The typical kernel standard is to fix bugs in patches and only reach
> > > for a wholesale revert if the community is struggling with bug
> > > fixing. Dmitry already tested removing that hunk, Robin explained the
> > > issue, we understand the bug fix is to remove the
> > > arm_smmu_init_domain_context() call. Nothing justifies a full scale
> > > revert.
> > 
> > I can't say I'm aware of any consensus for how to handle this, to be
> > completely honest with you. 
> 
> Well, I work in a lot of subsystems and this is a surprise to me and
> not something I've seen before. Fix the bug, move forward. Reverts are
> a cultural admission of failure. I use threats of a revert as a hammer
> to encourage people to pay attention to the bugs. I hardly ever
> actually revert things. What does reverting their code say to my
> submitters???

Huh. I guess I'm lucky never to have worked in a environment where that
is the case. In fact, my experience is quite the opposite: revert first
so that things get back to a working state and the developer/submitter
has some breathing room to rework the broken code. It's actually fairly
blameless if you get it right and when you have a half-functional CI it's
pretty much a necessity. Anyway, I digress...

So if you see me appearing to be heavy-handed with reverts when dealing
with regressions, it's really nothing tactical. Rather, it's purely
about keeping the driver in a known functional state.

> > > I'll send another patch if you want, but it seems like a waste of all
> > > our time.
> > 
> > It's a bug fix, of course it's a waste of time! We're talking minutes
> > though, right?
> 
> It becomes hard for maintainers to juggle the tress since you have to
> send the revert to -rc and the fix on top of the rc to next. Again, I
> will send the patch, just discussing.

I've never had any difficulty managing that, so I think we'll be ok.
Worst case, I can merge my fixes queue into my next queue.

Will




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux